Open Bug 200289 Opened 22 years ago Updated 3 years ago

Lack of consistency in placing downloaded files ("Desktop Folder")

Categories

(Firefox :: File Handling, defect)

Product:
Firefox
Component:
File Handling
Platform:
PowerPC
macOS
Type:
defect

Tracking

()

People

(Reporter: mightymik2, Unassigned)

References

Details

User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4a) Gecko/20030401 Build Identifier: Build ID: 2003040105 Does not follow Internet settings (users/<my name>/desktop), but will try:/System/Library/Frameworks/Carbon.framework/Versions/A/Desktop/<filename> (dead end) or:~/Library/Application Support/Chimera/Profiles/default/mf05uzop.slt/Cache/A7472E6Fd01-3 (huh?, at least the show in finder works here) (both of these in Build ID: 2003030613), (Build ID: 2003040105) will place it here:~/Desktop Folder/<file name> Problem is, you can't tell when it will go bad. Reproducible: Sometimes Steps to Reproduce: 1.go to site 2.download file 3.have fun finding the %@&*^* thing, if it d/l'd at all. Actual Results: file goes to wrong folder, gets spiffy random name so you can't tell what it is, or trys to go to a dead end. Expected Results: put it where i tell it to go (works with mozilla, but not el camino) Look where i want it to go...then put it there.
WorksForMe using Camino/20030402?? (build ID can't be found). Mik, can you reproduce this problem using a new Camino user profile? (That is, temporarily move your ~/Library/Application Support/Chimera/Profiles/default to another location, and start Camino.)
Summary: lack of consistancy in placing downloaded files. → Lack of consistency in placing downloaded files
Also, what exactly do you see in the "Download to:" field in Camino's Preferences/Navigation/Downloads?
let's see if this works... Build ID: 2003030613 is the bad boy here. I will see if i can move the directory... ok, i get 'Folder "A" on the volume "/" ' and got this as a result: /System/Library/Frameworks/Carbon.framework/Versions/A/Desktop/3dbunniesjellybeansx. sit the cancel and X buttons do nothing, and since this download was not successful, it will keep trying. (even during next session). so...YEP, reproducible. as to what i want to see... Whatever the selected target directory is...if 'use system preferences' is checked, then wherever internet says it should.
Sounds like something is very wrong on Mik's system, there is no way the Desktop folder should be inside the Carbon framework. I'd suggest a run of Disk Utility to test the directory structure of the drive. Modulo some issues with network mounted volumes (since fixed IIRC) Mozilla _does_ use the user's Download folder specified in the Web tab of the Internet pref pane of System Preferences. The other thing to suggest is try a new build. Build 2003030613 is almost a month old and may very well have some wacky problem (nobody ever said the nightly builds would be stable :-)
Camino version 0.7 (Build ID: 2003030613) Mac OS X 10.1.5 (Build 5S66) System: PowerMac G4 I've seen similar behavior with Camino as well. Sometimes Camino respects what I have selected as the download folder in my Internet Preferences (/Downloads), and then sometimes it goes to ~/Desktop Folder/<filename>. I haven't had any problems with the download not happening successfully, I'm just never sure of where Camino will put it. It does show in the download manager where it will put the file, so I'll know where to go when it downloads. However, prior to the download manager, it would put the download either in the Cache (where I couldn't find the file at all because of salted names) or in ~/Desktop Folder/<filename>. Again, the behavior was sporadic and (apparently) unpredictable. No changes made to the system. When Camino downloads a file to the wrong place (i.e., ~/Desktop Folder), I will double-check the preferences through Camino and it will show the ~/Desktop Folder as being the chosen folder. However, launching System Preferences and looking at my selection, it is still the correct folder (i.e., /Downloads). Usually, quitting from Camino and relaunching it solves the problem. The correct folder will appear in Camino's preferences and it will download files to the correct place.
I have run disk utility, and camino has behaves itself lately. :) Build 2003030613 is the build you get to download when you get to the Camino front page. if I may... " It does show in the download manager where it will put the file, so I'll know where to go when it downloads. However, prior to the download manager, it would put the download either in the Cache (where I couldn't find the file at all because of salted names) or in ~/Desktop Folder/<filename>. Again, the behavior was sporadic and (apparently) unpredictable. No changes made to the system." This sounds a lot like what i saw going on. the 'show in finder' button works here for when it sticks it in the cache. I would like to echo the unpredictability of it. It will work for a while, then out of the blue...oops. The trouble with the nightly builds is...which one do you grab? Was there one in the recent past that was clearly the best one in a long time?...i'm a user, not a developer . :) Still...it'll do till i can get to jaguar and safari.
Maybe this is an OS X 10.1.x-only problem.
Whiteboard: OS X 10.1.x only?
another possible clue...? Got another one into the cache today, when i d/ l'd a ZIP file. it's been fine for a while, maybe it freaked out because the .zip isn't a typical Mac file extention?
and the very next download ( a .wmv file) went where it was supposed to. curious. :)
*NOT* OS 10.1 only!! I am now runing Jaguar (10.2.5), went to download safari, which went here: ~/Library/Application Support/Chimera/Profiles/default/mf05uzop.slt/chrome/ Safari.dmg.bin. Camino says Folder chrome on volume /, even though internet pref is set to download 'to desktop'. When i went to open the camino prefs to double check, it NOW says folder quicktimeplugin.plugin on volume /. !!!! Yikes!
Mik, is the Camino application on a different volume than your ~ directory? Are you using any UFS volumes?
it's on the same volume, and it's a UFS formatted drive. It's not in the applications folder however.
Sounds like we still have a problem on UFS formatted volumes. Any ideas Conrad? Damn *nix geeks seem to think that's a good volume format to use for OS X :-)
The question is whether the problem is (1) getting the default download location or (2) some file handling bug after that. Mik, if you explicitly pick your downloads folder (option-click on a link to bring up save file dialog) for a download, does it end up in the right place?
Option-click appears to work properly.
Just a quick 'me to'. OS X 10.2.5, Camino 0.7. Tends to download deep into one of my projects build directories. Hugely annoying.
Gerd, does 'me to' also apply to your using a UFS partition?
Regarding: "Damn *nix geeks seem to think that's a good volume format to use for OS X :-)" Not all of us! My drives are HFS+; however, my home directory is an NFS mount.
Can anyone that has been able to repro this problem try a Mozilla 1.4blah build to see if it exhibits the same behavior? At this point we're thinking it's a Mac OS X bug as we're asking the OS for the DL folder location via an InternetConfig API and perhaps it occasionally does something odd on UFS volumes. If the problem is present in Camino but not Mozilla that theory goes out the window and we sacrifice some chickens to start the ritual, er investigation, of Camino's behavior.
Mozilla is well behaved. Camino will invent places to put files, like /private/ which DIDN'T EXIST. I hope the sacrificial chicken is kentucky fried.
in the event you're bored... the latest is that it won't even save the file as is...it renames it as an xml file. http://www1.korksoft.com/~schem/newamps/matchless_hotbox.pdf(source) turns into ~/Library/Application Support/Chimera/Profiles/default/mf05uzop.slt/bookmarks- 2.xml(destination) 10.2.6 is the current system.
this looks similar to bug 201427
*** Bug 201427 has been marked as a duplicate of this bug. ***
This bug apparently still exist in build 2003052104. Source: http://homepage.mac.com/ipage/ mactracker/downloads/mactracker.dmg.sit Destination: /Applications/Camino.app/Contents/ MacOS/chrome/installed-chrome.txt/mactracker.dmg.sit (instead of desktop). System 10.2.6.
i'm also seeing this, but (again) only on my desktop, whose profile resides on a UFS-formatted drive.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: OS X 10.1.x only? → UFS only?
STILL in as of the july 15 build. Build ID: 2003071505 Destination: /System/Library/Frameworks/ Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/BS_A03_RCI.pdf . This results in an 'Interupted'. Right click, and it's OK.
[1] -> Browser, as this happens in seamonkey, too. [2] see TB22724769Z for a crash in conjunction with this bug
Component: Downloading → File Handling
Product: Camino → Browser
Version: unspecified → Trunk
One other way this bug can happen (I've only reproduced it with Netscape 7.1 but the basic problem is still in the latest moz browser suite nightlies) is if you have preferences shared between multiple machines (such as our setup here with ~/Library symlinked into AFS; see bug 216204 for a description of that setup). For us, the user's home dir is still local, on an HFS+ volume, so it shouldn't be a UFS-only problem. The moz profile is on AFS, though, which looks like UFS to OS X. I can set the download directory fine on one machine and it'll revert to "~/Desktop Folder" when I go to another machine. See bug 201291 and bug 204548 for the more common manifestation of this problem. I've only had it select a random directory once (the german localization folder for the bluetooth driver!) but that's still possible behavior given that it's likely an alias problem. All of the machines at our site are configured automatically (using radmind) and have the same system files and file system layout, except for local data (user home dirs and /tmp, etc.), right down to the hard disk's name which is "System" everywhere. The problem seems to have something to do with moz or IC not being able to resolve the alias in the internetconfig.plist as a pathname rather than as an fsspec.
Build ID: 2003091302 1st d/l was OK , 2nd d/l altered the prefs file. just where does it get the idea to do this?
problem still in 11/05 build :((( Applications/Camino.app/Contents/Resources/English.lproj/BrowserWindow.nib/objects.nib/ic-208h.pdf
*** Bug 201291 has been marked as a duplicate of this bug. ***
Summary: Lack of consistency in placing downloaded files → Lack of consistency in placing downloaded files ("Desktop Folder")
Whiteboard: UFS only?
could it be...*GONE*?!?!?! oh no...how could you do such a thing? heheheh Looks like a LOT of work was done to the download manager, and in build 2004010303 (v0.7+) looks to behaving...though it has some minor nits (puts files into 'desktop folder', and not on the desktop proper), it looks like this might be the breakthru everyone needs. Good work guys...maybe needs to be released as 0.75 or so? off to try to break it some more...
Don't know if this should be a new bug, or added here. Is it me, or ... my prefs/navigator/downloads is missing the 'destination folder' setting. It just isn't there anymore. Downloads used to go to a 'downloads' folder, now they just pile up on the desktop. annoying. This is in the 1.6 OSX release. Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113
Pete: Did you update to Panther? If so, use Safari to set your download folder. And curse Apple for removing the UI to change the pref from System Preferences.
Not in Panther yet, still in 10.2.8. Found the setting in safari, changed it back to the folder I was using before, restarted mozilla, no joy. Everything still goes to the desktop. For compressed files/dmg's, the compressed file and the expanded file both end up on the desktop. Why is the pref taken out of mozilla, if it doesn't exist in the system prefs?
Pete: If you're still using 10.2.8 try changing the pref from the Internet pref panel in System Preferences and then log out to see if Mozilla picks up the change when you log back in. The pref was taken out of Mozilla when Apple made the Internet Config APIs part of the standard Mac OS and told developers they should start using them. Unfortunately Apple seems to forget that every time they rev Mac OS X.
I have changed it back several times in the internet prefs, but it doesn't 'stick'. trashed that plist file, reset it, but it keeps unsetting. I suppose I should quit everything, change it, reboot, etc. But something keeps losing the setting. Might have to go back to 1.5...
I think IE or Entourage used to be known for changing IC prefs back to their cached copy when they quit. You're not running one of them are you?
I'm still experiencing this in Firefox 3, Mac OS X Tiger. If a file is just "opened", rather than saved, it goes to the Desktop, even though my Download folder is set as something else. Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1
This is still happening in 3.0.5 with Leopard.
This stinking bug has cost me a good three days of quality time. As I used Firefox, my desktop would get clutterd with all the pdf files I looked at. I finally found a work-around here: http://forums.mozillazine.org/viewtopic.php?f=39&t=552309&start=30&st=0&sk=t&sd=a To paraphrase the mozillazine post, the work-around is to 1) Uninstall Safari 3.04 (Using AppDelete, free s/w available here: http://reggie.ashworth.googlepages.com/appdelete ) 2) Install Safari 2.04 which is available here: http://michelf.com/projects/multi-safari/ 3) Quit Firefox and any other browsers. 4) Use the newly installed Safari 2.04 to set the target folder for downloads to something other than the desktop. (I have a folder called "browser_downloads".) 5) For good measure, reboot. The problem is fixed! For the sake of completeness, this worked for me in this context: Mac Powerbook G4, OSX 10.4.11, Firefox 3.0.11. The problem was that setting the download target folder in Firefox's Prferences>Main>"Save files to" setting did not actually change the folder where files went. This bug showed up only for files that required helper applications, such as .pdf files, .dmg, .zip and so on. It appears that Apple has changed the way Safari save this preference. I personally find it strange that Firefox relies on Safari to set its preferences. (There must be a good reason for it. Could someone explain it?) Peter Halverson
QA Contact: chrispetersen → file-handling
Product: Core → Firefox
Version: Trunk → unspecified

The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.

Assignee: sdagley → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.