Closed Bug 55628 Opened 24 years ago Closed 24 years ago

'helperAppLauncher.xul' will not overwrite file of same name

Categories

(SeaMonkey :: UI Design, defect, P3)

Product:
SeaMonkey
Component:
UI Design
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: jrgmorrison, Assigned: mscott)

References

(
URL
)

Details

(Keywords: dataloss, Whiteboard: [rtm need info])

Attachments

(1 file)

proposed fix for just the exthandler and not to nsIFile::MoveTo
1.40 KB, patch
Details | Diff | Splinter Review 
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).
Keywords: rtm
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."
Keywords: dataloss
re-assigning to me. I think this bug is mine. I'll post a patch.
Assignee: law → mscott
I believe we had a similar problem in mail attachments.  Is the solution going
to be to uniquify the name?  Another dialog?
Whiteboard: [rtm need info]
*** Bug 55837 has been marked as a duplicate of this bug. ***
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.
Whiteboard: [rtm need info] → [rtm+]
changing to rtm+ for real now.

rtm++
Whiteboard: [rtm+] → [rtm++]
fix checked into branch and tip.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
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.
Severity: normal → major
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
Whiteboard: [rtm++] → [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.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Whiteboard: [rtm need info] → [rtm++]
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.
Whiteboard: [rtm++] → [rtm need info]
okay, vrfy on branch for only winnt and linux.
Keywords: vtrunk
vrfy using opt comm trunk bits 2000.11.13.08 on winnt and linux.
Status: RESOLVED → VERIFIED
Keywords: vtrunk
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: