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:
Adding keyword dataloss, dogfood, and nsbeta3 as a potential candidate...
reassigning to jefft.
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?
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....
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.
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.
Thank you selmer. :)
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.
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
Fix checked in.
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.