Closed Bug 303416 Opened 20 years ago Closed 20 years ago

Firefox updates will only work on with a complete or one word directory.

Categories

(Toolkit :: Application Update, defect)

x86
Windows XP
defect
Not set
major

Tracking

()

RESOLVED DUPLICATE of bug 303598

People

(Reporter: davebate, Unassigned)

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050804 Firefox/1.0+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050804 Firefox/1.0+ The update prgram will only work with directories that are one word or complate with no spaces. Reproducible: Always Steps to Reproduce: 1.Install at normal defalt locations (Deer Park Alpha 2 or Mozilla Firefox) 2.Run install update 3.Does not install 4.Reinstall clean to a directory with no spaces (Firefox) 5.Run install update 6.Update completes install. (YES!!! FINALLY!!!!) Actual Results: After re-installed Firefox to new directory with no spaces, the update program works fine. Expected Results: The update program should work in any directory (spaces or no spaces) as per normal default naming by former and present install. (Deer Park Alpha 2 or Mozilla Firefox). Either the Update program iw fixed for any type of directory name or the Install group should change the default location to just Firefox (or something with no spaces).
What version of Firefox were you attempting to update from? This bug has been fixed for a week or so. At least it definitely WORKSFORME with recent builds. Perhaps you were experiencing bug 300404?
I just tested this with Thunderbird with yesterdays build as well and the same thing happens. Directory has to have no spaces to work properly. Program Files/Deer Park Alpha 2 - Does not update Program Files/Mozilla Firefox - Does not update Program Files/Firefox - Updates properly Program Files/Mozilla Thunderbird - Does not update Program Files/Thunderbird - Updates properly I tested this with yesterdays build "0803" for both Firefox and Thunderbird. It never worked at all till I changed the directory names with ones with no spaces. Now it works perfectly. I am wondering if the spaces should be replaced with the URL character for space as some programs will do, or just have the programs install in "no space" program directories. I bet the updater program is **** out on the spaces. It only see's "Deer" or "Mozilla" on the present install directories and doesn't see anything so it exits.
I read that bug and looks to me was something seperate from directory names, atleast that is the way it started. This deals with the spaces in directory names and as tested this morning with 0803 build, once I used directory with no spaces it worked perfectly. I believe this is a seperate issue from bug 300404 as it related to the directory names. Window programs always seem to have problems with spaces in directory names unless it is coded just right and I think we fell into the "Gate Name" or "Gates%20Name" issue.
Just tested "0801" build and the same thing.... Once I get ride of the spaces in the directory, it works fine...
I have exactly the same setup (same installation directories), and yet I do not observe this bug :-( How are you invoking Firefox to launch it? Does it matter if you choose the Later option or the Restart Now option in the software update dialog?
Today's test only used the Restart Now option. I'll test the later button next. I know it (Later button) didn't work yesterday when I was playing with it, with the default install directories.
Just tested the Later button with 0803 and the same thing. With space in the directory, it doesn't work. Without spaces it works fine. It installed the latest version on the very next restarted. This was the forced update. Not sure if the automatic update works. Don't know when it does it's own self check or if it does, but only looks for released versions and not the nightly versions...
I have always had deer park installed in C:\Program Files\Deer Park Alpha (1/2) and have used the software update feature since the test url was first released and I have never seen a problem with this. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050803 Firefox/1.0+ ID:2005080306
I don't know then what the difference between our two Windows 5.1 systems would be where it works for you with the deer park directory name and mine didn't. All I know is that someone in the MozillaZine forums mentioned that he saw a replay about the spaces in the directory and that it caused people problems. I tried it and now it works. That's all I know. Don't know what to say. If the Updater is using reg entries to get the location, the only thing I can think of is that the reg entries are taking three different formats. I had this problem before while programming C++ a while back. Either the reg is using: C:\PROGRA~1\DEERPA~1\FIREFOX.EXE or C:\Program Files\Deer Park Alpha\Firefox.exe or "C:\Program Files\Deer Park Alpha\Firefox.exe" Some programs, depending on the code, will have major proplems with the second option above. In that case it needed quotes or use the DOS version with no spaces, compressed with the ~1. Some programs needed the quotes to use the format with spaces. I had a starellite tracking program give me a devil of a time to work and it wasn't till I changed the reg entries to include the quoted format. I could test that next. Just a thought. Again, not knowing the code used by firefox/thunderbird, I could be way out in left field, or not in the park at all. :)
David, When the failure occurs, do you see the updater process run at all? After the failure occurs, can you save off the contents of the updates/0/ directory? This directory exists under "C:\Program Files\Deer Park Alpha 2\" It'd be great if you could attach the update.log file to this bug report, and tell me what the update.status file has in it. Thanks!
In the default "Program Files/Deer Park Alpha 2" directory... After downloading the updates and I click on the reboot to update button, firefox/thunderbird will close and that is it. Nada happens. In the update/0 directory is: update.mar update.status updater.exe update.ini The update.status has just "applying" in it. I cannot find an update.log. Once I reopen firefox/thunderbird, the normal windows opens, with a smaller Software Update in behind stating the Update Available notice and it has two buttons (Later and Download & Install Now). At this point the files in the update/0 directory, were just deleted and when you click the Download & install button another window will open with License Aggreement with an red exclamation symbol in the notice box with I disagree, the only button enabled (the others are back and I agree, both grayed out). Once I click I disagree button, of course it closes and all that is open is the main firefox window. I took an hour and tested the reg entries using quotes ("C:\Program Files\Deer Park Alpha 2\firefox.exe") and using the PROGR~1\DEERPA~1\FIREFOX.EXE changes for the file locations and it still would not work. When I re-install to "Program Files\Firefox" and "Program Files\Thunderbird" directories, with no spaces, the updater runs fine and the program is updated. The updater runs right after firfox closes and you can see the installation bar during the install. Hopes this helps???? I wonder if it is the call to the updater that has the problem with spaces in the Deer Park or Mozilla Thunderbird directory names and not in the registries? Is it being called as: C:\Program Files\Deer Park Alpha 2\Updates\0\updater.exe <blahblah> or as Deer Park Alpha 2\Updates\0\updater.exe <blahblah> ???? Just curious..
Thanks for the additional info. Is your filesystem NTFS or FAT32? When Firefox launches updater.exe, it uses the "short" path name (i.e., the one with the "~" characters). So, I'm really surprised that spaces would be an issue.
NTFS all the way.... :)
I hit my reg and security notes from my Microsoft courses most of the night and was wondering if you can tell me what the status of the following key. I think I found the problem why it works for some and not others. Please check the: "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem set NtfsDisable8dot3NameCreation" and see if it is a 1 or a 0 (zero). If the key is a 1, the Updater will not work with spaces in the directory name. If the key is a 0, Updater will work with any. Dave Townsend (Mossop)- I bet your key is set for 0 as you stated that it is has been working. Usually it is set to 0 by default, but some reg clean and speed up your system programs will set this to 1 to disable 8.3 to speed up your system. When you set this back to 0 it should fix all. I havn't tested it yet, (will when I actually wake up) but I am almost 100% sure it will fix the problem.
The only down fall to this is that any directories that were created while the key was set to 1, will not have short or 8.3 directory names. Firefox and thunderbird will have to be deleted totally and re-installed with the new directory once the key is set to 0. DIR /X will tell you if you have no shortnames for some directories, as you can see below.. C:\Program Files>dir /x Volume in drive C is Windows XP Volume Serial Number is 41C0-830D Directory of C:\Program Files 08/05/2005 12:15 AM <DIR> . 08/05/2005 12:15 AM <DIR> .. 05/24/2005 03:27 PM <DIR> Adobe 07/12/2005 07:32 AM <DIR> Ahead 03/06/2005 05:36 AM <DIR> ALWILS~1 Alwil Software 08/01/2005 07:13 PM <DIR> Ashampoo 08/05/2005 12:15 AM <DIR> Bradbury 07/31/2005 03:39 PM <DIR> COMMON~1 Common Files 03/25/2005 10:58 PM <DIR> FILEZI~1 FileZilla 08/05/2005 12:25 AM <DIR> Firefox 07/31/2005 03:39 PM <DIR> Gaim 08/04/2005 12:51 AM <DIR> GnuPG 12/08/2004 08:14 PM <DIR> HIGHMA~1 HighMAT CD Writing Wizard Any directory without 8.3, were created when the key was set to 1 and the others were created when windows was setup to the time it was set to default 0. As you can see my Firefox does not have a 8.3 short name, so there is the problem.
Oppss. Sorry almost forgot. Once you change the key back to 0, you will have to reboot. The key is not an active key iand is only read during boot up only. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem set NtfsDisable8dot3NameCreation = 0 (Default)
*** This bug has been marked as a duplicate of 303598 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
Version: unspecified → Trunk
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.