User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:188.8.131.52) Gecko/20071127 Firefox/184.108.40.206 Build Identifier: version 220.127.116.11pre (20080124) Email attachments, dragged directly from the attachment list at the bottom of a mail window to a destination folder, will silently overwrite a file of the same name without asking for confirmation first. Reproducible: Always Steps to Reproduce: Setup: 1. Create a destination folder called "foobar". 2. Inside foobar, create a file called "testattachment", containing the word "original". 3. Arrange to have an email in your inbox with attachment also named "testattachment". It should contain the word "replacement". (I emailed myself such a file) 4. You now have a sample destination folder with original file, and an email with an attachment of the same name as that file. Ready! Execution: 1. Open the email with "testattachment" attached. 2. Drag "testattachment" into the folder "foobar". 3. Open the overwritten file inside "foobar" to verify that the file has been overwritten and now contains the word "replacement". Actual Results: The file "testattachment" was overwritten instantly. Expected Results: Thunderbird should have given a prompt to confirm before overwriting, as if one had just right-clicked and selected "save as..." and directed saving into folder "foobar". I claim this bug to be major because it involves accidental data deletion; apologies if this is over-ranked.
I confirm that the bug is reproducible also on my machine which has the following configuration: S.O: Mac OS X 10.5.7 Build 9J61 Thunderbird version: 18.104.22.168 (20090812) I also think that this is a critical bug because it involves accidental data deletion as it already happened to me. I do not think it is over-ranked.
Mail.app properly asks the user if it is allowed to overwrite the same-named previous file with the attached one. Thunderbird does not -- it simply overwrites the file, with no indication to the user. I am able to reliably reproduce the bug on Snow Leopard. Simply dragging to the Desktop (on the Mac, it is also a "folder") will easily reproduce. OS: Mac OS X 10.6.1 Platform: Intel Mac Thunderbird version: 22.214.171.124 (20090812) This bug's symptoms have now made an appearance on a well-read Macintosh news site: http://www.macintouch.com/readerreports/snowleopard/index.html#d29sep2009
I can also confirm this bug can be reproduced for Thunderbird 3.0 beta 4.
Confirming as per comment #3 and Ludovic's bug 501364, comment #4. This should be a blocker: Immediate and unexpected dataloss for an everyday action (drag'n'drop of attachment to folder). Seems to be platform-specific on OS X, but we should check other platforms to make sure.
Severity: major → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: dataloss, platform
Hardware: PowerPC → All
Summary: when dragging attachments to folders, files are overwritten without confirmation → [MAC OS] Dragging attachments into folders overwrites existing files with same name without confirmation (Drag-and-drop, overwritten, no warning)
Would block for a day, but not a week. This may be a Gecko bug; adding qawanted to find out if Firefox has the same problem.
Flags: blocking-thunderbird3? → blocking-thunderbird3+
Priority: -- → P2
Giving to philor, in the hopes that he'd be willing to take a run at it. Failing that, please at least offer up a snarky or amusing comment.
Assignee: nobody → philringnalda
On Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:126.96.36.199) Gecko/20090824 Firefox/3.5.3 If I drag the same image twice from flickr to a folder - the second time the image name as -1 append to it. So not a Core bug.
Keywords: platform, qawanted
sadly, no amusing comment :-) since I love debugging on the mac so much, I'll take a look at this.
Assignee: nobody → bienvenu
Created attachment 406696 [details] [diff] [review] possible fix this fixes the problem on the mac - I've ifdef XP_MACOSX because Windows prompts the user on drop (or at least Vista and Windows 7 do). I'm not sure what Linux desktops do. I'll try to figure out what Firefox does.
Whiteboard: [no l10n impact] → [no l10n impact][has patch for r/sr Standard8]
Whiteboard: [no l10n impact][has patch for r/sr Standard8] → [no l10n impact][ready to land]
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Whiteboard: [no l10n impact][ready to land] → [no l10n impact]
You need to log in before you can comment on or make changes to this bug.