53238 - Data loss: attachment option "Save All" fails to prompt user if destination dir has an existing file w/ same file name.

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect, P2)

Description

[pmock]

Build Date & Platform Bug Found: 
 win32 commercial seamonkey build 2000-091906-m18 installed on P500 Win98
 macos commercial seamonkey build 2000-091904-m18 installed on G3/400 OS 9.04

Overview Description: 
 Reported by Jeff Tsai.  If you receive a message that contain 2 different with 
the same name and try to save all the attachment at once, the 1st attachment 
will be overwritten by 2nd attachment.

Steps to Reproduce: 
1) On your hard drive, select two different files such as a gif or jpeg
   Recommend the file being different file size to make it easier to recognize.
2) Rename one of the file with the same name as the first.
3) Start seamonkey
4) Open Mail
5) Start a new mail message
6) Address the mail message to yourself and type in a subject title
7) Attach both files
8) Send the mail message
9) Get Mail
10) Select the mail message
11) Click on the attachment paperclip icon and click "save all"
12) Select your location and click ok
    The 1st attachment is saved then overwritten by the 2nd file attachment.

Actual Results: 
 The first file is downloaded and saved to the hard drive then is overwritten by 
the 2nd file attachment.

Expected Results: 
 We should either ask the user for a different file name or automatically make 
the 2nd file a unqiue file name.

Additional Builds and Platforms Tested On: 
 In Communicator 4.7x, we automatically prevented the 1st file from being 
overwritten by adding a "-1, -2, etc" numeric number to the file name to make it 
unique.

Additional Information:

Comment 1

[pmock]

Adding keyword dataloss, dogfood, and nsbeta3 as a potential candidate...

Comment 2

[scottputterman]

reassigning to jefft.

Comment 3

[selmer (gone)]

Isn't the workaround to simply save the first attachment separately?  If so,
that would negate the data loss portion of this.

I find it difficult to believe this is a dogfood issue.  Does this happen to you
often for some reason?

Comment 4

[pmock]

I find this behavior very distrubing and serious because
 a) not prompting the user that it deleting a file is not user friendly.  In 
this simple case with 2 files, it easy to see.  If I had many attachments, it 
becomes harder to save attachment individually.
 b) it dataloss because a user will not know that the 1st file is missing.  What 
if the user deletes the mail message after saving the files?  
 c) I don't usually attach two different file with the same name, but I can see 
were someone might run into this situation if they send 2 revision of the same 
file, e.g. code changes or report changes...
 d) It dogfood now because there is a more serious scenario.  The "Save All" 
will replace an "existing" file on your hard drive if it happens to be the same 
name as the attachment you are trying to save.  It silently replaces the file.  
I know I would be upset if I overwrote a file by mistake.  Try this scenario:
 1) In a test directory, copy a file into the directory.
 2) In another directory (source), rename a different file and call it the same 
name as the 1st file.
 3) Start seamonkey
 4) Open mail
 5) Start a new message 
 5.5) Attach the 2nd file and one other attachment different from the test 
directory.
      You need at least 2 attachment to have the "Save All" option available.
 6) Address the message to yourself, add a subject title, then send the message
 7) Retrieve the message
 8) Use the "SAVE ALL" option to save the file attachments to the test directory 
that contains the 1st file.
    It will wipe out the file in that directory.

This bug can be re-summunarize as: attachment option "Save All" fails to prompt 
user if destination dir has an existing file w/ same file name.

Old summary: a loss: saving 2 attachment w/same name will overwrite 1st file

Re-submitting for evaluation.... 
Clearing white board info ... Updating summary....

Comment 5

[jefft]

I have to agree with Peter as we discovered this bug yesterday.

I used to have a statement to make sure every attachment has its own unique name
when the first time I implemented the "save all" feature. For some reason it
gets deleted.

A typical and easy to reproduce example is to forwarding a couple or more
forwarded messages and then receive the mail and does a save all. As one can see
all the forwarded message has the display name set to "forward.msg". Forwarding
forwarded messages will have all the display names set to "forward.msg". Do a
save all will only have the last forward.msg saved because the file gets
overwrite over and over again. If a user think he can save all the attachments
for viewing later and delete the original message after the save then this is a
serious data loss.

The right solution for this is to pop up a dialog box ask user for replacing the
existing file and then prompt for another file name if the user decided not to.

Recommending for nsbeta3+, dogfood.

Comment 6

[selmer (gone)]

Thanks for the clarification.  Marking nsbeta3+, P2 due to reasonably frequent
data loss scenarios.  Not much time left for P2s though...

I still don't buy the dogfood argument, but nsbeta3+ should suffice.

Comment 7

[pmock]

Thank you selmer. :)

Comment 8

[Phil Peterson]

PDT agrees P2, and we wouldn't want to ship with this bug, even though Save All
may not be the most frequently used thing.

Comment 9

[jefft]

Attachment: a fix

Comment 10

[Jim Roskind]

I don't think this would really stop folks from using the product.  The file is 
not saved, but it strikes me that it would be apparent very quickly that this 
was the case (my habbits lead me to use files soon after I save them).  I don't 
believe that "Save All" is an exceptionally common command to use, and the 
work-around is all too obvious (save 'em one at a time).
Marking dogfood-minus

Comment 11

[jefft]

Fix checked in.

Comment 12

[pmock]

Verified as a fixed on win, linux, and macos using the following builds:
 win32 commercial seamonkey build 2000-092509-m18 installed on P500 Win98
 linux commercial seamonkey build 2000-092508-m18 installed on P200 RedHat 6.2
 macos commercial seamonkey build 2000-092511-m18 installed on G3/400 OS 9.04

Verified on trunk b/c branch has not occured.