Closed Bug 286094 Opened 20 years ago Closed 16 years ago

"Save all attachments to this folder" preference option ignored

Categories

(MailNews Core :: Attachments, enhancement)

Product:
MailNews Core
Component:
Attachments
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 9309

People

(Reporter: chris.a.mis, Unassigned)

References

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1 The "Save all attachments to this folder" preference has been enabled and a directory on my default system drive is selected. My installation is not standard in that I do not use a default C:\ system drive identifier to thwart script kiddies. Attachments are not directed to this folder. All attachment apprear to continue to be saved in the default location. Reproducible: Always Steps to Reproduce: 1.Chose Save all attachments to this folder 2.Select folder on system drive 3. save preferances and restart client. Actual Results: Mail with attachments is received but the attachment is not placed in specified folder but rather to default mail folder. Expected Results: Placed the attachment into the specified folder.
Version: unspecified → 1.0
Well, I can certainly confirm that this is still an issue in 1.0.2. I tested Thunderbird on a Windows XP machine (with SP2). Expected Results: Attachments are detached from messages and saved to specified location when new messages are retrieved. Actual Results: Nothing!
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
This is still an annoying issue. The bug is still there in 1.0.6 and 1.5 Beta 1. As for the expected result: Either TB could automatically save all attachments to the configured folder, or at least, when the user selects to save the message, not prompt for the folder, since the user configured it. Like in Firefox, there is a "download" folder, so all downloads go there.
But still appears in 1.5 beta 1
There has never been a facility to auto-save attachments to a certain place on reciept of the email. The preference is there as an alternative to asking where to save the attachement each time when you right click on an attachment in an email chose 'save'.
Actually, Andrew (the previous author) told me this: It should have been the 'open' option I mentioned. Double click on an attachment or chose 'open'. It gives the option to open or save. If you chose save it saves to the download folder. You can check a box to always save or always open. If you tell it to always save that type of attachment to disk then it will save the the download folder when you double click it. --------- In fact, if you double click an attachment, it will display the open dialogue. In there one can choose to always save to the configured default location. So I guess it all works as designed and the bug should be closed.
If what Chris is saying is that Thunderbird should propose a folder to save to (like Merome suggests in bug #235402) , then I agree that this would be a very helpful feature. An annoyance that is related to this issue is when you choose "Save All...", then create a directory using the little create directory button, it automatically jumps into that directory. This is an annoyance because you have to "select" the directory to save images to from it's parent directory. It should just stay in the current directory when you create a new folder instead of 'cd'-ing into it.
(In reply to comment #7) > An annoyance that is related to this issue is when you choose "Save All...", > then create a directory using the little create directory button, it > automatically jumps into that directory. See Core bug 205606.
(In reply to comment #5) This isn't the way it's supposed to work. Eudora handles this properly; when an attachment comes in, the attachment is put into the folder that the user selects as "save all attachments to" in the first place; no hiding the attachments in the mail folder. If the user picks a spot they want attachments to go to, then they want them to go there in the first place, rather than have to deal with plucking them out of heavens-knows-where. This preference in Thunderbird needs to be fixed so that it will behave this way, which is proper. (In reply to comment #6) "So I guess it all works as designed and the bug should be closed." But it doesn't. "Save all attachments to this folder" isn't saving them to that folder. At all. My attachments folder still has 0 items in it despite receiving over a dozen attachments yesterday alone. I'm encountering this same bug on version 1.6a1 (20051205) (with tab enhancement) on OS X. Someone change it to "ALL" OSes, because I'm not a Windows user. It won't let me do it, and the report is falsely restricted to Windows 2000.
(In support of Comment #9 from burfalcy@gmail.com ) >This isn't the way it's supposed to work. Eudora handles this properly; when an >attachment comes in, the attachment is put into the folder that the user >selects as "save all attachments to" in the first place; no hiding the >attachments in the mail folder. This was the intent of my original posting. It seems daft that attachments (binary or otherwise) would be buried within the mailbox proper when one can specify a location for attachments. My personal preference is to treat the "Attachment Folder" as a quarantine area and hence my concern with the current behaviour. Also, please note that this "Bug" was filed against the program function located under "Tools/Options/Attachments/" called "Save all attachments to this folder:" NOT "Save all attachments to this folder when specified by user to save attachments:"
OS: Windows 2000 → All
(In reply to comment #10) Also, please note that this "Bug" was filed against the program function > located under > "Tools/Options/Attachments/" called "Save all attachments to this folder:" > NOT > "Save all attachments to this folder when specified by user to save > attachments:" Indeed that's the section that's bugging me (sorry for the pun). I think it's a little confusing to have two different dialogs for saving attachments. I would have expected opening an attachment to just launch the default handler for that type of file using the Finder (mac) or Explorer (windows) or whatever window system is set up in Linux, and open the file.
This annyoing bug is still present in ThunderBird 2.0b1 (20061206) OS X (Jan 2007) As in previous versions of TB preference settings for saving attachments are ignored. AFAIK the only exception to this was TB 1.5.0.9, where this bug appeared to be gone. However, no warranty for this statement, since my experience with 1.5.0.9 is limited. I consider this behavior of TB to be a bug, since the preference settings as specified by a user ought to be honored with highest priority, regardless of any other settings, let alone system wide default settings. But ThunderBird (as well as FireFox) have this bad habit of always and only using the system wide download folder (under OS X set by preferences in Safari, sic). Relaunching TB after editing the preference settings, never helped. This is a most annoying behavior, especially if one has a folder action installed on the download folder or if someone uses such a folder as a quarantine area, possibly also using virus protection processes etc. In my case (folder action active) TB looses all attachments and any workflow is interrupted, which makes working with attachments impossible and defies any serious use of TB. IMHO TB has to honor with first priority any download folder as specified in the preferences dialog, regardless of what any other settings are, including system wide settings. Any distribution/dispatching of attachment files (e.g. through action settings, save as dialogs etc.) have to take place afterwards, i.e. after the attachment file has been downloaded by TB to the user specified folder.
FWIW, the preferences that TB is setting are "browser.download.dir" and "browser.download.useDownloadDir" and I think they function similarly to the preferences in the suite -- which, as near as I can tell, is as described in comment 6. The suite's Save All Attachments behaves just as Thunderbird does, requiring the directory to always be specified. And *that* Save As dialog defaults to the directly in "messenger.save.dir"; the same directory is used when you save a message, which is additionally annoying if you're trying to keep attachments in one place as saved messages in another. My about:config listing for TB also shows "browser.download.downloadDir" -- I'm not sure how this is handled differently, but it's apparently always set to match "browser.download.dir". There's also "browser.download.lastDir": if you right-click on a link in an HTML message and "Save Link Target", there (again) seems to *always* be a Save As dialog, defaulting to that pref's directory. (TB should at least change the menu item to "Save Link Target As..." if it's going to behave that way.) I completely agree this is all confusing.
Assignee: mscott → nobody
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Component: Preferences → MailNews: Attachments
Ever confirmed: true
Product: Thunderbird → Core
QA Contact: attachments
Hardware: PC → All
Version: 1.0 → Trunk
Mike, I don't quite get what you try to convey. The preferences you are talking about should simply be honored by TB, that's all. That is not confusing, but simply a bug. TB behaves not as it should and seems to ignore those preferences (unless I define an action). This is what happens in the latest TB (4th Mar 2007) when attempting to access (double-click) an attachment for which no action is defined: a) Global setting (preferences) for Attachments is "Save all attachments to this folder:" and an existing folder (in my case: /Volumes/HD/uaf/Documents/ThunderBird Folder/Attachments) is given. b) I double-click the attachment and I am given the following dialog: You have chosen to open 'TestFile.p' which is a: Pascal source from: imap://mail.ethz.ch:993. What should Thunderbird do with this file? I select option "Save to Disk" and click "OK". c) TB uses the global download folder (and not the one specified under a) above). The result is a corrupted file, since I have a folder action active for the global download folder: Saving TestFile.p /Volumes/HD/uaf/Documents/ThunderBird Folder/Attachments/TestFile.p could not be saved, because an unknown error occurred. Try saving to a different location. "OK" Now, if I have a TB action defined for files with extension .p I can circumvent the error, since only then does TB honor the globally specified download folder to be used. However, for the file type used in above example I have no action specified. Then TB makes the mistake to NOT use the folder specified, but uses instead a system wide global download folder. Note, the confusing error message indicates otherwise. However, that is wrong, since I find corrupted, portions of the file in the global download folder. The latter proves that TB is using the wrong folder. IMHO this is CLEARLY a BUG of TB. It should use for the download only the folder as specified in the preferences. Mike, I don't quite get it what you are trying to convey. The preferences you are talking about should simply be honored by TB, that's all. But unfortunately TB behaves not as expected and seems to ignore its own preferences for downloading attachments (unless I define an action). This is what happens in the latest TB 1.5.010 (20070221) under MacOS X when attempting to access (double-click) an attachment for which no action is defined: a) Global setting (preferences) for Attachments is "Save all attachments to this folder:" and an existing folder (in my case: /Volumes/HD/uaf/Documents/ThunderBird Folder/Attachments) is given. b) I double-click the attachment and I am given the following dialog: "You have chosen to open 'TestFile.p' which is a: Pascal source from: imap://mail.ethz.ch:993. What should Thunderbird do with this file?" I select option "Save to Disk" and click button "OK" c) TB uses the global download folder (and not the one specified under a) above). The result is a corrupted file, since I have a folder action active for the global download folder (moving downloads to subfolders named according to download date): "Saving TestFile.p /Volumes/HD/uaf/Documents/ThunderBird Folder/Attachments/TestFile.p could not be saved, because an unknown error occurred. Try saving to a different location. OK" Now, if I have a TB action defined for files with extension .p I can circumvent the error, since only then does TB honor the under a) specified download folder and uses it to save the attachment to it. However, for the file type used in above example I have no action specified. Then TB makes the mistake to NOT use the folder specified, but uses instead a system wide global download folder (OS X, Safari is typically used to define that folder, by default Desktop). Note, the confusing error message as indicated by TB. It gives a path to the wanted folder for the file in question, but does not use it! That is quite confusing, since in fact TB does not use that folder. The proof is that I find corrupted, portions of the file in the global system-wide download folder, not the TB download fodler. This fact proves that TB is messing things up and appears to use both folders at the same time, one of them the wrong one. IMHO this is CLEARLY a BUG of TB. It should use for the download only the folder as specified in the preferences. BTW, these are my settings while producing above described behavior of TB version 1.5.010 (20070221), i.e. the following is an excerpt from prefs.js: user_pref("browser.download.dir", "AAAAAAF0AAIAAQJIRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADBn4tnSCsAAAABso4LQXR0YWNobWVudHMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGykMF33OMAAAAAAAAAAP////8AAAkAAAAAAAAAAAAAAAAAAAAAElRodW5kZXJCaXJkIEZvbGRlcgAQAAgAAMGffVcAAAARAAgAAMF3ztMAAAABAAwAAbKOAADG1wAAjWgAAgAvSEQ6dWFmOkRvY3VtZW50czpUaHVuZGVyQmlyZCBGb2xkZXI6QXR0YWNobWVudHMAAA4AGAALAEEAdAB0AGEAYwBoAG0AZQBuAHQAcwAPAAYAAgBIAEQAEgAtL3VhZi9Eb2N1bWVudHMvVGh1bmRlckJpcmQgRm9sZGVyL0F0dGFjaG1lbnRzAAATAAsvVm9sdW1lcy9IRAD//wAA"); user_pref("browser.download.downloadDir", "AAAAAAF0AAIAAQJIRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADBn4tnSCsAAAABso4LQXR0YWNobWVudHMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGykMF33OMAAAAAAAAAAP////8AAAkAAAAAAAAAAAAAAAAAAAAAElRodW5kZXJCaXJkIEZvbGRlcgAQAAgAAMGffVcAAAARAAgAAMF3ztMAAAABAAwAAbKOAADG1wAAjWgAAgAvSEQ6dWFmOkRvY3VtZW50czpUaHVuZGVyQmlyZCBGb2xkZXI6QXR0YWNobWVudHMAAA4AGAALAEEAdAB0AGEAYwBoAG0AZQBuAHQAcwAPAAYAAgBIAEQAEgAtL3VhZi9Eb2N1bWVudHMvVGh1bmRlckJpcmQgRm9sZGVyL0F0dGFjaG1lbnRzAAATAAsvVm9sdW1lcy9IRAD//wAA"); user_pref("browser.download.folderList", 2); user_pref("browser.download.useDownloadDir", true);
Above comment got corrupted due to an interrupted internet connection. I commit it once more for clarity reasons: _________________________________________________________________________________________________ Mike, I don't quite get what you try to convey. The preferences you are talking about should simply be honored by TB, that's all. That is not confusing, but simply a bug. TB behaves not as it should and seems to ignore those preferences (unless I define an action). This is what happens in the latest TB 1.5.010 (20070221) (4.Mar.2007) under MacOS X when attempting to access (double-click) an attachment for which no action is defined: a) Global setting (preferences) for Attachments is "Save all attachments to this folder:" and an existing folder (in my case: /Volumes/HD/uaf/Documents/ThunderBird Folder/Attachments) is given. b) I double-click the attachment and I am given the following dialog: "You have chosen to open 'TestFile.p' which is a: Pascal source from: imap://mail.ethz.ch:993. What should Thunderbird do with this file?" I select option "Save to Disk" and click button "OK" c) TB uses the global download folder (and not the one specified under a) above). The result is a corrupted file, since I have a folder action active for the global download folder (moving downloads to subfolders named according to download date): "Saving TestFile.p /Volumes/HD/uaf/Documents/ThunderBird Folder/Attachments/TestFile.p could not be saved, because an unknown error occurred. Try saving to a different location. OK" Now, if I have a TB action defined for files with extension .p I can circumvent the error, since only then does TB honor the under a) specified download folder and uses it to save the attachment to it. However, for the file type used in above example I have no action specified. Then TB makes the mistake to NOT use the folder specified, but uses instead a system wide global download folder (OS X, Safari is typically used to define that folder, by default Desktop). Note, the confusing error message as indicated by TB. It gives a path to the wanted folder for the file in question, but does not use it! That is quite confusing, since in fact TB does not use that folder. The proof is that I find corrupted, portions of the file in the global system-wide download folder, not the TB download fodler. This fact proves that TB is messing things up and appears to use both folders at the same time, one of them the wrong one. IMHO this is CLEARLY a BUG of TB. It should use for the download only the folder as specified in the preferences. BTW, these are my settings while producing above described behavior of TB version 1.5.010 (20070221), i.e. the following is an excerpt from prefs.js: user_pref("browser.download.dir", "AAAAAAF0AAIAAQJIRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADBn4tnSCsAAAABso4LQXR0YWNobWVudHMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGykMF33OMAAAAAAAAAAP////8AAAkAAAAAAAAAAAAAAAAAAAAAElRodW5kZXJCaXJkIEZvbGRlcgAQAAgAAMGffVcAAAARAAgAAMF3ztMAAAABAAwAAbKOAADG1wAAjWgAAgAvSEQ6dWFmOkRvY3VtZW50czpUaHVuZGVyQmlyZCBGb2xkZXI6QXR0YWNobWVudHMAAA4AGAALAEEAdAB0AGEAYwBoAG0AZQBuAHQAcwAPAAYAAgBIAEQAEgAtL3VhZi9Eb2N1bWVudHMvVGh1bmRlckJpcmQgRm9sZGVyL0F0dGFjaG1lbnRzAAATAAsvVm9sdW1lcy9IRAD//wAA"); user_pref("browser.download.downloadDir", "AAAAAAF0AAIAAQJIRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADBn4tnSCsAAAABso4LQXR0YWNobWVudHMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGykMF33OMAAAAAAAAAAP////8AAAkAAAAAAAAAAAAAAAAAAAAAElRodW5kZXJCaXJkIEZvbGRlcgAQAAgAAMGffVcAAAARAAgAAMF3ztMAAAABAAwAAbKOAADG1wAAjWgAAgAvSEQ6dWFmOkRvY3VtZW50czpUaHVuZGVyQmlyZCBGb2xkZXI6QXR0YWNobWVudHMAAA4AGAALAEEAdAB0AGEAYwBoAG0AZQBuAHQAcwAPAAYAAgBIAEQAEgAtL3VhZi9Eb2N1bWVudHMvVGh1bmRlckJpcmQgRm9sZGVyL0F0dGFjaG1lbnRzAAATAAsvVm9sdW1lcy9IRAD//wAA"); user_pref("browser.download.folderList", 2); user_pref("browser.download.useDownloadDir", true);
This bug is related to the forum topic http://forums.mozillazine.org/viewtopic.php?t=506460 which I have recently updated to inform about the behavior of latest TB with respect to this bug. I can report the following: The preferences settings for which folder to use for attachments is still ignored as of TB version 2.0.0.5 (20070716). With version 2.x the old bug has been reintroduced again, in contrast to TB 1.5.0.9, where the preference settings were honored. I reported this bug also for TB, 1.5.010 (200070221), TB 2.0b1 and now for the latest 2.0.0.5 (20070716). All TB versions use wrongly only the Safari (=system wide) determined download folder instead of the one specified by the peferences. I know unfortunately of no technique to circumvent this annoying behavior of TB. I wish to emphasize once more, this is a most annoying behavior if one has a folder action installed on the system wide download folder. TB looses all attachments and any workflow is interrupted. IMHO TB has to honor with first priority any download folder as specified in the preferences dialog, regardless of what the system wide settings are. What I can report though with respect to the latest TB 2.0.0.5 (20070716) is that the action settings are at least honored and some of the problems I described earlier are now gone. Yet, I repeat, I believe that TB has to honor its own settings as made in the preferences dialog and I consider what I report on not a mere plea for an enhancement, it is actually clearly a bug. Could please someone deal with this? I guess this should not be such a big deal to fix, since it most likely only concerns the sequence by which specifications for the download folder are recognized and if all is modularly programmed, the rest of the code dealing with attachments should be hardly affected. Andreas Fischlin
I have version Eudora 8.01b and it's still doing this. How can I find my attachments? I've looked everywhere I can think of and there is no sign of them. Eudora is working with TB platform and Penelope (not familiar with that). Thanks! Molly (In reply to comment #10) > (In support of Comment #9 from burfalcy@gmail.com ) > > >This isn't the way it's supposed to work. Eudora handles this properly; when an > >attachment comes in, the attachment is put into the folder that the user > >selects as "save all attachments to" in the first place; no hiding the > >attachments in the mail folder. > > This was the intent of my original posting. It seems daft that attachments > (binary or otherwise) would be buried within the mailbox proper when one can > specify a location for attachments. My personal preference is to treat the > "Attachment Folder" as a quarantine area and hence my concern with the current > behaviour. > > Also, please note that this "Bug" was filed against the program function > located under > "Tools/Options/Attachments/" called "Save all attachments to this folder:" > NOT > "Save all attachments to this folder when specified by user to save > attachments:" >
Agree this needs to be fixed. Potentially causes other issues on the Mac as well, Bug 434638 for example. Firefox honors the preference... wish Thunderbird did. Confirmed BROKEN in nightly Thunderbird version 3.0a2pre (2008071203)
The pref is working as intended - it's just not doing what you want, which is bug 9309 (or one of its dependencies). Closing this one as duplicate.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
Could you please explain what you mean by "is working as intended"? According to all my testing the pref does NOT work at all. Moreover, I do not see a close relationship to bug 9309. Bug 9309 does rather relate to temporary file storage. On a Unix system like Linux or OS X one should use directory /tmp for such purposes. Of course it would alternatively be possible to use also the same folder as specified in the pref, but then ThunderBird would need to make sure it deletes all temporary files properly, what seems to be main issue with bug 9309. I consider it a preferably philosophy to keep temporary file storage and permanent file storage separate and use different folders for both. In my view it is clear that the pref relates only or first of all to permanent storage of attachments. To distinguish between the two would mean that if the user wishes merely to open an attachment, say a pdf in Adobe Reader or a doc file in Word, that the attachment file is downloaded to the temporary file location such as '/tmp'. However, if the user wishes to save to disk, then a permanent storage is intended and tha attachment file should be saved to the folder as given in the pref. To my dismay I have never observed any of these behaviors with ThunderBird. To conclude: In my view it does not help to close this bug as a duplicate of 9309. On the contrary, since I believe bug 286094 to be a real bug, probably the cause for the many other bugs, i.e. 238789, 243975, and 238789, I regret very much that you have closed this bug. The usability of ThunderBird suffers a lot from this, given the fact that so many users send attachments these days.
Some afterthought: Given the messy discussions on the bug 238789, bug 243975, bug 238789, and bug 286094, it appears to me to be really advisable to clearly separate user issues from real software bugs. The now unfortunately closed bug 286094 is at the basis of the buggy behavior of ThunderBird while handling attachments on Mac machines and should be reopened. It appears to me to be of little help to blur user issues with underlying actual software bugs. The situation risks to get even more confused. Please Magnus, revert the closure.
I hear there are some issues on mac, yes. (But that's not this bug.) However, bug 9309 is not about temporary storage. I wrote "working as intended" because well, see comment 5 and 6 which are correct. Molly: attachments are stored in the mails - the work for penelope is bug 359319 (which may end up being bug 9309).
This bug is wacky. On re-reading it I can see why Magnus Melin pointed to Bug 9309, because he doesn't understand what we are talking about. I have to admit when I first read this bug, I did NOT get the message that it is about wanting attachments auto-detached and saved in a folder off by themselves from emails. That makes no sense for IMAP, maybe for POP. This bug is not something I would ever want. I want a default save folder when I click "Save As..." or "Save All..." I guess I'll have to open yet another bug for that, though I am sure someone with better Bugzilla Search Foo can find a duplicate that it will be marked as. Ah screw it, I don't care enough... I'll just work around the problem.
For me, the confusion stemmed from my experience with using Eudora before coming to Thunderbird. In Eudora, "save all attachments to this folder" implied the specific action of detaching attachments from all incoming messages automatically and placing them in the specified folder. The preference of the same name in Thunderbird does not do that but simply sets the default folder in the context of the Save As... and Save All... actions for attachments. One cannot fault the Thunderbird GUI for previous user experience from elsewhere. Nowhere on the Attachments Preferences dialog for Thunderbird is there mention of attachment detachment. Given that the group title is "Attachments Folder" and that the two options are "Ask me where to save every file" and "Save all attachments to this folder:", I think it's pretty clear that the GUI is talking about a Default Attachments Folder and not attachment detachment.
It's interesting that you call the storing of attachment files in a folder detachment. AFAIK this is always done, i.e. any attachment is always a separate file as soon as you do something with it from within the mail client. This is inevitable for technical reasons and has nothing to do with any experience with a previous GUI such as having used Eudora or other mail clients. An attachment is a separate file and as a file has to be stored somewhere, i.e. in a folder, as soon as you do something with it. This is all also independent from POP or IMAP. Having said that, I believe we can disentangle this mess a bit: From reading the discussions and watching what TB does, I guess I now better understand what some of the various comments are talking about. As soon as I open, save as, double-click, or ctrl/right-click an attachment, a temporary file is created on my local machine. TB stores those temporary files in the system-wide download folder. This is the bug I am talking about. Only later on, i.e. when I decide to really save the attachment to disk, does TB copy the attachment file to the folder as specified in the pref. I understand now, that the pref has nothing to do with this temporary storage location, but only with the final destination of the attachment files when I choose a save on disk option. I agree that TB as I am using it now does behave that way. I interpret Magnus' comment #20 (this bug 286094) in this manner. TB stores eventually the files in the pref I have specified. In that sense I agree now to close this bug. However, the problem remains, that I can never successfully handle any attachments exactly because TB is using the system-wide download folder for temporary storage. BTW, some of you called this use of temporary storage a not-detached attachment. But note, in fact the attachment file is alreayd far away from the TB application and the TB folder ('~/Library/Thunderbird'). What is needed is that TB uses another folder for temporary storage, e.g. '/tmp', not the system-wide download folder (under Leopard, OS X 10.5.x this is folder '~/Downloads'). The latter is typically used for many purposes, e.g. quarantine or folder actions as on my systems. Thus TB can not assume that it can safely use the system-wide download folder for temporary storage. It should also not make a mess there, since that folder is possibly used also by many other applications (ftp clients, browsers etc.); see also bug 238789. In this context it may also be of intereste to remember that pre Leopard OS X's used the Desktop as the default location for the system-wide download folder. Note also, that confusingly for many users, Safari prefs allowed to change that folder, despite the pref was a system-wide pref; a most confusingly programming as done by Apple, which is responsible for many comments made to bug 238789. Conclusions: 1) There may indeed be no need to reopen bug 286094, but to open a new one (see point 2 below). To avoid the confusion I was victim of, however, I suggest to rephrase the pref 'Save all attachments to this folder' as follows: When saving attachments to disk use this folder: This would reduce the risk of misunderstandings. 2) To fix the problems as I have described them under this bug and to avoid any interference with the use of the system-wide download folder, TB should satisfy its temporary storage needs by using another location, I suggest /tmp. If the latter is used, there is no need to have an additional pref. If that's not the case, then TB has to use also a pref for that folder. That may not need to be made controllable for any end user by offering it at the GUI (menu command "Thunderbird -> Preferences... -> Attachments"). Editing file 'prefs.js' may be all what is needed to give some control over the folder used for temporary storage.
I try to explain the problem. When I want a single attachment to be saved, I Click on Save as and I see the last used directory, which is original behavor. This is still working like this. When I want to save all attechments, I click on Save all and I always see the "My documents directory", instead of the last used, what is was.
I revise my conclusions from comment #26 after having revisited bug 311292: 1) There is no need to reopen bug 286094, but I suggest to make a fix nevertheless. To avoid the confusion I was victim of, I suggest to rephrase the pref 'Save all attachments to this folder' as follows: When saving attachments to disk use this folder: This would reduce the risk of misunderstandings. 2) Bug 311292 for FireFox is related to bug 286094 for ThunderBird and describes exactly the same problem, temporary storage done in the system-wide download folder. It needs urgently a fix by no longer using the system-wide download folder. I expect this will make TB (and possibly also FireFox) handle attachments (or donwloads) in future versions properly and in a usable way. This is a most crucial issue as the many bug reports and forum discussions demonstrate (bug 311292, bug 374184, bug 243975, bug 238789, for forum links see https://bugzilla.mozilla.org/show_bug.cgi?id=374184#c19). P.S.: Contrary to what bug 311292 for FireFox reports, I do no longer see this problem with FireFox 3.0. Any donwloaded file ends up in the pref defined folder and I do no longer see any temporary files stored in the system-wide download folder. Unfortunately that is NOT the case with ThunderBird 2.0.0.14 (20080421). Thus bug 311292 could be closed for FireFox, but needs to be reopened for ThunderBird 2.x. Unfortunately I have not been able to make any tests with a prerelease of ThunderBird 3.x.
Attachments appear to be embedded in messages or "non-detached" from the user's perspective. As a user, I don't really care what Thunderbird uses for its "temporary storage folder". Then again, some users may. Getting back to the issue at hand, from the Attachments Preferences dialog, it is clear to me that the "Save all attachments to this folder:" preference refers to a Default Attachments Folder. I use XFCE4 on Fedora Core 9 and Thunderbird 2.0.0.14, and I can confirm that this preference has absolutely no effect when I "Save As..." an attachment or "Save All..." all attachments.
Yes, this may well be the case. But as a programmer I know that in the end behavior needs to be implemented properly and bugs can only be fixed in the implementation. I tried to be helpful to the programer's by pointing out the difficulties I encounter. That "Save As..." and "Save All..." are not influenced by the preference "Save all attachments to this folder:" is perfectly fine, since those commands throw a dialog at you in which you are asked where to save the attachment files. That's not a bug. If you merely do a "Save", e.g. by double-clicking the attachment symbol at the bottom of the E-mail message and then choose option "Save to disk", only then the preference matters. The problem I have been describing has rather to do with the poor formulation of the preference, which leads easily to misunderstandings. Therefore I suggest now to deal with this issue (bug 286094) by changing the preference text to When saving attachments to disk use this folder: Then ThunderBird should be fine with respect to attachments with the exception of the temporary storage problem as described under concusion point 2 in my comment 28 above.
(In reply to comment #30) > Yes, this may well be the case. But as a programmer I know that in the end > behavior needs to be implemented properly and bugs can only be fixed in the > implementation. I tried to be helpful to the programer's by pointing out the > difficulties I encounter. > > That "Save As..." and "Save All..." are not influenced by the preference "Save > all attachments to this folder:" is perfectly fine, since those commands throw > a dialog at you in which you are asked where to save the attachment files. > That's not a bug. If you merely do a "Save", e.g. by double-clicking the > attachment symbol at the bottom of the E-mail message and then choose option > "Save to disk", only then the preference matters. The problem I have been > describing has rather to do with the poor formulation of the preference, which > leads easily to misunderstandings. Therefore I suggest now to deal with this > issue (bug 286094) by changing the preference text to > > When saving attachments to disk use this folder: > > Then ThunderBird should be fine with respect to attachments with the exception > of the temporary storage problem as described under concusion point 2 in my > comment 28 above. > After some three years I am thrilled to see the discussion that this issue has generated. Ultimately, as users it is clarity in the user interface that we all want to see achieved. In that respect I can concur with Andreas's comments that a rename of the function would be most helpful. Ie, to use the following string " When saving attachments to disk use this folder:" Thank you to all the users that have posted in helping to improve what is already an excellent product.
Indeed an excellent product, which we try to make even better. :-) ;-) :-) Andreas
Filed bug 446291 about the clarifications.
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.