Overview Description: The dialog 'helperAppLauncher.xul', when presented with a situation where the user has requested, in the file picker, to overwrite a file of the same name, will fail to do this overwrite. The previous version of the file is retained, despite the user request (and the time expense of doing a large download since the download is actually done, but the save/rename is not completed). Steps to Reproduce: 1) go to www.mozilla.org 2) try to download one of the .zip, .gz, .bin files linked to at the bottom right corner of the page (e.g. "Window, Irix, ..."). 3) when the dialog comes up, save it a foo.exe in some directory, and let the download and save finish. 3a) optional: do the equivalent of 'echo "whatever" > foo.exe' for mac and win32, so you know the contents are different. 4) now do another download, and try to save this as 'foo.exe' again. The file picker asks for permission to overwrite the existing file, Say OK to the overwrite. 5) Let the download then proceed, and check the file when it is complete. Actual Results: the old file is retained, the new download is discarded. Expected Results: Since the user said to overwrite this file, then the app should do so (of course). Build Date & Platform Bug Found: 20001006nn win2k, mac and linux branch MN6 builds

Nom. RTM, as this is a huge inconvenience for the user, and I imagine the fix for this is not particularly involved. (but law must really be hating me by now).

not sure if dataloss is the right word here...but if something isn't saved when the user expects it, it kinda falls under "not getting the data i wanted."

re-assigning to me. I think this bug is mine. I'll post a patch.

I believe we had a similar problem in mail attachments. Is the solution going to be to uniquify the name? Another dialog?

*** Bug 55837 has been marked as a duplicate of this bug. ***

r=sspitzer.

sr=alecf. Moving to rtm+ status so PDT can look at this today. I've verified that this works on windows and the Mac. I'm about to try Linux now. Note: I opted to just fix the exthandler case with MoveTo. I'm sure other people have the same problem where the move fails if the file already exists. But since we don't have rtm specific bugs to address those problems, I chose to leave the current implementation of nsIFile::MoveTo alone and to instead isolate the change to just the case we can test which is through the exthandler in this scenario. Post RTM I'd suggest we implement MoveTo correctly.

changing to rtm+ for real now.

rtm++

fix checked into branch and tip.

vrfy fixed using opt comm branch bits 2000.10.11.09-n6 on linux and winnt. however, when i try this out on the mac, the file isn't replaced --it's completely deleted. reopening. here are my steps: 1. go to same page as jrgm uses. 2. click the Macintosh link, and select Save on Disk. 3. i change the filename to "foo.bin" and have it saved on the desktop. 4. wait for it to download (it's about 9Meg in size). 5. click the Linux link, and follow steps 2-3. when asked whether to cancel or replace, click Replace. 6. wait for the download to complete. result: when download progress is done, the file foo.bin disappears completely (not even in the trash). ouch. so, the original file is thrown away (expected), but the new file somehow doesn't get saved.

Hmm this is working for me on my Mac using a .bin file from www.mozilla.org (in the nightly build panel).

This does the same for me on Mac saving to the desktop -- the second download results in having _no_ copy of the file (i.e. the delete succeeds but the subsequent rename/move fails).

Okay I looked into this problem a little more. I believe the problem ONLY exists on the Mac when you are saving to the desktop. I was saving to another folder on my mac when I verified this bug and it works for me there. The problem is that, the Mac represents the desktop in two fashions. Here's some example paths to a .bin file on my desktop: HD:mozilla.bin HD:DesktopFolder:mozilla.bin Before I delete the existing file the user chose for the final destination, I make sure it isn't equal to the temp file I'm currently saving the helper app content into. Obviously, I don't want to delete the file I just downloaded. So I have two nsIFile objects that I call nsIFile::Equals on. On the mac, this is just a string comparison for the file names. As you can see from my example, the paths are slightly different even though they end up pointing to the same place on the desktop. cc'ing some Mac gurus in case they have some suggestions on how we can fix nsLocalFileMac::Equals to properly determine if two nsIFile objects point to the same file...

Simon/Mike, it seems like nsLocalFileMac::Equals is not implemented correctly. It currently just gets the path from each nsIFile and does a string comparison. Shouldn't it be doing something like getting the FSSpec and then comparing the two specs? Or some other kind of permament file descriptor? Forgive me if my Mac lingo is lacking =).

These are two different locations: HD:mozilla.bin is on your hard drive. HD:DesktopFolder:mozilla.bin is on the desktop. Barring 2 volumes with the same name, file paths should be a reliable way to distinguish between files on Mac.

oops right you are....I was smokin' some good stuff when I wrote that. Sairuh/John, I can't seem to reproduce this in my debug build. But I was doing the Mac .bin file over and over again. I just realized that your steps said the second file you click on is the Linux tarball. I just stepped through the debugger and discovered that the problem is with the file name for the linux download!!! Maybe Pinkerton and Simon can help us out. I have a nsLocalFile object which is a path to my desktop (HD:DesktopFolder). This was created using a FSSpec and not a path. I'm appending the following file name to this spec: mozilla-i686-pc-linux-gnu.tar When I try to get the path for this file object after the append call, the path is totally bogus. We get an error deep down in ResolvePathAndSpec. When we try to merge the appended path onto the original file spec bad things seem to be happening. In the end, I'm getting path that points to a folder which already exists (very whacky at this point). In short, we fail to create this file so we fail to write the content to the temp file. Then later on, we delete the original file and we have nothing to move over 'cause the temp file was never created. I think we should spin out a separate bug for this and leave this bug as closed. I'll need some help debugging nsLocalFileMac from someone.

please clear the rtm++ status when reopening. resetting to rtm need info.

"mozilla-i686-pc-linux-gnu.tar" is 31 chars long, which hits the Mac filesystem file name length limit. There needs to be some code somewhere that canonicalizes filenames to be within length limits, and unique. This code also needs to preserve file extension.

Simon, I take it we don't have any such code in nsLocalFileMac that does this today? I'm going to open a new bug to track this and will cc the everyone here. I'm going to reclose this bug.

nsIFile has CreateUnique() which should do the right thing.

Yes I already use CreateUnqiue (actually I helped add it with Dougt =)). But the problem is the nsLocalFileMac object is already corrupt before I call create unique. Appending a file name > 31 characters immediately corrupts the entire object. I had an object that looked like: "HD:DesktopFolder" I append the file name to it expecting to get "HD:DesktopFolder:mozilla-etc.tg" which I then call CreateUnique on. However, the FSSpec has been corrupted and points to a random location after resolving with the appended path. For me that meant: "HD:Seamonkey:viewer-debug" (or something like that). Which is a folder. Let's move further discussion into the new bug I filed: 56295.

okay, vrfy on branch for only winnt and linux.

vrfy using opt comm trunk bits 2000.11.13.08 on winnt and linux.