Fog Creek Software
Discussion Board




Setup was a bit of a bust :-(

Hi Joel,

I saw what you wrote regarding the whole setup process.  Naturally, I was excited.

Unfortunately, in reality, it didn't work like that.  I tried several times to run the setup program--and I would get to see errors saying "Unable to Rename Directory", and it would fail--no advice on what to do, nothing.

I contacted the technical support line.  But the unfortunate thing was tech support told me I needed to reboot the machine.

So I rebooted--same problem.

*Sigh*

John R. Troy
Monday, November 04, 2002

That generally means that a file is being held open in the FogBUGZ directory by some process. We try to stop all the processes which might be holding open a file -- IIS's web server, Index server if it's running, and Dispatcho (a part of FB 3.0 which you presumably don't have yet).

Joel Spolsky
Monday, November 04, 2002

What the heck could be holding it open though...

The only thing running after the install is the reboot.  I

I'll do a new installation, but I don't want to lose the current database.  :-(

John R. Troy
Monday, November 04, 2002

Hi John,

I'm the one you spoke with on the phone.

Unfortunately the problem is that something is holding on to one of the files in your FogBUGZ folder.  I told you to reboot because usually this will free up the folder.

Since it did not, I have two suggestions.  First, please make sure when you downloaded the setup.exe file, you did not download it into the FogBUGZ directory and run it from there.

The next likely candidate is a service.  We stop IIS and also the indexing service.  You could try stopping these services manually and see if that helps.

Finally, try moving the subfolders within the fogbugz subdirectory (website and accessories).  Go into the folder that failed to move and try moving all the files into another folder.  This will help you find which file is locked and won't allow itself to be deleted or moved.

Once you find this out, you can use this freeware app (NTHandle) http://www.sysinternals.com/ntw2k/freeware/handle.shtml
to find which process has the file locked.

I'm sorry you didn't have a 100% experience with the setup program, but the problem isn't in setup itself.  It's simply that an app or service on your system has the directory locked.  The only way to work around that is to quit the app or stop the service.  We stop all known services that would have the FogBUGZ directory open.  Unfortunately on your system, something unknown has done that...

Michael H. Pryor
Monday, November 04, 2002

Finally figured it out--took me a few hours though...

I just gave up and installed a new release.  It looks like there wasn't any sort of file lock, but it was becoming locked during the install.  I think it was hanging up on that "new compontent"--the service you created to manage licenses.

I did a fresh install.  Then I did a DTS import of the old database--I screwed up the Status table though, which I finally fixed.

One suggestion--if you encounter a locked file, you should allow a reboot, or have a setup that handles it.  I hate to say it, but I've had a much easier time with Microsoft software, Allaire, and other stuff that required a reboot than with this particular one. 

I would not make mention if it, save that you guys made such a big deal about setup being painless and not requiring any sort of reboot.  If this kind of setup is what I expect to experience--I would have to say it would've been better for one that was more manual than this one.

Though I do love the actual application.  :-)

John R. Troy
Monday, November 04, 2002

I think what I'll do to solve these problems in the future is to tweak SETUP a little bit so that if it can't move the old stuff out of the way, it creates the new installation alongside the old one. That way you won't need a reboot even if a file is in use.

Joel Spolsky
Monday, November 04, 2002

I encountered two small problems with the setup myself.  I worked around them and wouldn't mention them except for the fact that Joel seems to take such pride in improving his software and here are two opportunities.

First, the setup program suggested installing FogBUGZ in c:\Program Files, thing is I don't have a c: drive, Win2K resides on e:.  Setup should probably consult %SystemDrive% environment var.

Second and a little more vexing was the problem of IIS crashing during the second part of the install because Norton AntiVirus silently blocked the ASP scripts attempt to write to the disk.  Rummaging around the FogBUGZ site I found the workaround doc and got through it.  I would expect the setup program to be a little more proactive.  Either setup.exe could test if the NAV exe is running and popup a dialog, or maybe the ASP script could somehow test whether it can write to the filesystem and give an error if it can't.  Just watching a spinning IE logo and blank page in my browser is frankly a bit frustrating.

On the whole  though Kudos to Joel (and Mike) for excellent software, these are minor complaints and easy to see how they slipped through.

Ken Klose
Tuesday, November 05, 2002

Thanks for the feedback!

We actually don't have c:\ hard-coded anywhere, we ask the OS for the location of the Program Files directory.

What do you have in your registry for
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir ?

Second question -- Norton. What OS are you using? We're aware of the Norton Anti Virus annoyance but no matter how hard I try, I can't even install NAV on a server operating system. It refuses to install because it's not supported by Symantec on servers. Even though a lot of people somehow manage to have it running. I've been trying to find a way to detect if Norton is running and warn users during setup but I can't even get it installed :)

Joel Spolsky
Tuesday, November 05, 2002

I see two possible relevant entries under \HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Current Version
ProgramFilesDir : REG_SZ : E:\Program Files
ProgramFilesPath : REG_EXPAND_SZ : %ProgramFiles% (%ProgramFiles% evals to E:\Program Files in a DOS window)

The OS I'm running is Windows 2000 Professional, using Norton SystemWorks 2002.05 Build 72.  I've got all the latest patches from windowsupdate and Symantec liveupdate.

Ken Klose
Tuesday, November 05, 2002


It's weird -- we just call this windows function which is supposed to return the correct path to Program Files, and on your machine it is returning c:\..., even though you're obviously on e:\. I will try to track this down.

(What happened to your C: drive, anyway? ;)

I'll try again to write some code to detect & warn about Norton Anti Virus.

Joel Spolsky
Tuesday, November 05, 2002

C: came with the computer as IDE0, D: (the CD-ROM) was IDE1.  I upgraded to a Maxtor ATA/133 drive that uses its own ATA controller (a PCI expansion card) that the OS recognizes as something similar to a SCSI card.  SCSI cards get the next drive letter after the onboard controller (that's E:).  (I've even got a CD-RW (F:) and second HD (G:) hanging off the ATA/133 card).

I'd be happy to test either of the fixes you're working on, feel free to float me an email if you have anything you'd like me to run.

Ken Klose
Tuesday, November 05, 2002

Joel is correct in saying that the normal version of Norton AV won't install on Win2k server.

However the corporate version of Norton (which has a completely different UI to the normal version) will happily install on server as well as professional.

Andy Norman
Sunday, November 10, 2002

While the comments regarding running NAV on a server OS may be true, you obviously don't need to have a server OS to run FogBUGZ. As a matter of fact, I'm pretty sure that I saw that Ken was running it on Win2k Pro, which has no constraints against NAV.

Couldn't you use such an environment/setup for your SETUP tweaks, Joel?

Erik Noble
Wednesday, November 13, 2002

*  Recent Topics

*  Fog Creek Home