Any FrontPage / Windows server gurus: weird folder behavior

First off, a disclaimer: I’m a web designer and do not like FrontPage. Dreamweaver is my favored tool, next to good ol’ EditPad. But it’s not my decision to use FP on one of my client’s websites. The client set up her website using FP97, and she insists on continuing to use it to edit files directly on her server (ugh), so I’m stuck. At least I’ve been able to move to FP2003, which is slightly better. (Generally I make sure to keep the code view visible so that I can easily remove any FP crappy code.)

All this preamble is to say that all y’all FP-haters don’t need to tell me it sucks. Believe me, if I had my druthers, I wouldn’t be using it.

Okay. So the client’s test site recently underwent a change of webhosts. This moved them from a IIS 5.0 box to a IIS 6 box. Now, many of these pages use ASP includes, which used the syntax “<!–#include virtual =”…/assets/filename.txt"–>". Suddenly all of these includes stopped working, and threw up error messages kvetching about the “…/” usage. Apparently IIS 6 doesn’t allow parent paths by default.

I contacted the new hosts about this, and they flipped the switch to allow parent paths. But in addition, the host’s techies went into the client’s files on their own and changed the “virtual” includes references to “file.” I was a little miffed – not that the change was required, but that they went in and futzed with the files without telling us, and did it using a global search/replace. This basically means that now many of our test server files are different from our live site, and I have to check all our folders one by one to see which ones were altered.

But the biggest problem is that for some reason, the folder where we keep our “includes” files – a folder named “assets” – is no longer visible in FrontPage. It’s definitely on the server, because I can go directly to one fo these includes files in a browser. But when I open up FrontPage, or when my client does, or even when the webhosts do, the “assets” folder is invisible.

The weirdest thing is that it appears to be just the name that’s causing a problem. Consider:

  • The folder itself isn’t set to “hidden” or anything like that. If the host techies rename it something else using FTP, the folder suddenly shows up in FP’s folder list.

  • If I try to create another new folder named “assets”, FP warns me that the folder already exists.

  • If I create a new folder in FP, named “assets_2”, and then rename that to “assets”, the folder disappears the instant I rename it. Like Keyser Soze … poof, and it’s gone.

So apparently FP just has up and decided to hate on the name “assets” out of the blue. Does anyone have any suggestions on why this is happening? Could it have anything to do with corrupted FP extensions? The hosts reinstalled FP extensions but that didn’t seem to do anything.

I am no FP expert so this is beyond my ken. Help!

I would be miffed at that too.

But I’d be reasonable with them, and just say “please don’t do such things again without asking us first”. Followed by “Will you be able to have them all changed back by 5pm today, or will it take until tomorrow?”

If they did it without your permission, they should be expected to change it back. And since they did it with a global search/replace, they can easily undo it the same way.

Nothing teaches people not to mess with your files without permission like having to go through the effort of undoing it!

Amen! Oh my, yes, I would love to be able to do that! But the solution to our seemingly corrupted FrontPage extensions is probably going to be uploading our backup files from before the techies futzed with 'em, so there’s no point in making them undo everything just to have it overwritten.

Still don’t know the answer to this bizarre aversion FP has developed to the folder name “assets”, though.