Open Bug 1769423 Opened 2 years ago Updated 8 months ago

Pid folders created when opening attachments - contains saved copies of files which used 'Open with' option.

Categories

(Thunderbird :: General, defect)

Thunderbird 91
Unspecified
All
defect

Tracking

(Not tracked)

People

(Reporter: anjeyelf, Unassigned)

Details

Attachments

(1 obsolete file)

Windows 10 OS
After update possibly 91.6.0 (10th feb 2022) or 91.6.2 (8th March 2022), when I open attachments, a 'pid-xxxxx' folder is now being created in Users/User Name/Appdata/Local/Temp folder.
My oldest pid folder is dated 11th March 2022.
The 'pid-xxxxx' folder contains a copy of the actual attachment eg: *.jpg, *.mov, *.pdf, *.xlxs, invite.ics etc
The 'pid-xxxxx' number corresponds to the program thunderbird.exe
If I open an attachment more than once, then a duplicate is created eg: *(1).jpg is created in same pid-xxxxx folder.

In prefs 'browser.helperApps.deleteTempFileOnExit' is set as true

Result is I have a lot of 'pid-xxxxx' folders which are not removed by Thunderbird upon exit. They are consuming quite a lot of space as they are not .tmp files; they are full copies of the opened attachments as if they have been 'saved'. I am not selecting to save these files - just using the 'Open with' preset option.

I notice the following information in release notes which may or may not be related.
91.6.0
Fixed: Attachments filenames were not sanitized before saving to disk

91.6.2
Fixed: Temporary files from opened attachments were saved with world-readable permission

Another user also reports the same issue and also reports the opened files are not editable (opening in read-only mode - expected) but those opened read-only files no longer have any option to select to edit.

I have discovered that if I access the 'pid-xxxxx' folder and open one of the *.jpg files the 'rotation' option is greyed - close image - right click on image icon/file and choose 'properties' allows me to uncheck the 'read-only' and click on 'Apply'. I can then open that image and the eg: 'rotation' option is now available. However, why should anyone need to locate hidden Temp folders just to locate the attachment they want to open. Sounds crazy to me especially when you have not selected to save any file at that point.
see Support Forum:
https://support.mozilla.org/en-US/questions/1376172

For Microsoft Office - Word, Excel etc there is the Trust Center Settings, where you can set up to allow opening of attachment from emails not using the 'Protected view', however this seems to be ineffective and has stopped offering the ''Enable Editing' button.

Why are 'pid-xxxxxx' folders being created?
Why are attachments which use 'Open with' (not save file) being 'saved' as copies in the 'Temp'/'pid-xxxxxx' folder ?
If you use the option "What should Thunderbird do with this file? Save As ....." instead of "What should Thunderbird do with this file? Open with ....." then you do not get the pid-xxxx folder.
But the 'Open With' is in effect saving the files which is not expected nor wanted.

Expect:
No 'pid-xxxxxx' folder to be created
No auto saving of 'Open With' attachments.
Option to choose to switch to editing mode.

If people are not mentioning this issue, it is possible that users are not aware of the auto saving of opened attachments in newly created pid folders. It is not usual to check the Appdata/Local/Temp file on a regualr basis. You would not expect 'open with' files to be auto saved anywhere without being specifically 'Saved as' in a chosen location.

Summary: Pid folders created when opening attachments → Pid folders created when opening attachments - contains saved copies of files which used 'Open with' option.

These 'pid' folders are not Windows OS specific - they are created in eg: Linux Ubuntu in eg: file://tmp/pid-xxxx

https://www.reddit.com/r/Thunderbird/comments/u2un7i/change_openned_attachment_temp_location/

https://github.com/mozilla/releases-comm-central/issues/48

The pid- folders are created so that in multi user environments the file names would not leak to other users. I think not required on windows, but I don't see it hurting either.

Re auto-saving for open with: that definitely need to happen. Always happens. How else could a program open a file?
There's no way of knowing if a previous file with same name is the same file, so each opening needs to create a new file.

The file is read-only because it's opened in a temporary location. We want to prevent someone from spending time editing the document only to lose it afterwards.

We do set the file to be deleted on application closing.

I can confirm this is happening on Ubuntu 20.04 LTS with Thunderbird 91.8.1

pid folders are being created in the tmp folder and are not removed upon exit, plus as was mentioned by the OP, if you open the same attachment more than once it creates a duplicate in the pid folder.

One thing I have noticed is that if you have Thunderbird configured to preview pdf documents within Thunderbird, it does not create a pid folder. If you instead have it configured to open using an external PDF reader, the pid folder is created.

The pid- folders are created so that in multi user environments the file names would not leak to other users. I think not required on windows, but I don't see it hurting either.

The pid folders are in the 'Temp' folder and they are not created as temporary folders and they do not contain temporary files. They are not being deleted. The number of pid folders is increasing by the day and the amount of space being consumed by all the saved files is not acceptable. Whist some attachments may be a few hundred kbs, jpg and mov files are not exactly as small

The pid folders and the saved files they contain are within the User Account Appdata folder, so anyone with access to the User Account can access those pid folders. As the files they contain are apparently saved in those pid folders they can be opened and edited and copy pasted to anywhere. This history storage feature of opened attachments being auto saved without the users knowledge and no means of auto deletion is wrong and needs fixing.

Re auto-saving for open with: that definitely need to happen. Always happens. How else could a program open a file?

Agree, you expect a tmp file to be created when using 'Open with' in order to open the file and you expect the tmp file to be cleared when exiting Thunderbird.
You do not expect permanent folders to be created nor non temporary files to be saved and nothing deleted upon exit. - This is the problem and it needs fixing.

We do set the file to be deleted on application closing.

Any created .tmp file in the 'Temp' folder is deleted. But this topic is not about those files.
Neither the 'Open with' saved attachment file nor the pid folder are deleted.

The file is read-only because it's opened in a temporary location. We want to prevent someone from spending time editing the document only to lose it afterwards.

As an opened attachment, it cannot be edited - eg: images which Thunderbird has a problem with orientation cannot be rotated

However, in the currrent situation, if they were not read-only, editing would be perfectly ok because the files are not temporary -therefore even if the person editing did not choose to save to a suitable location, the files would not get lost because thunderbird already auto saved the file in the pid folder. I have opened the files in the pid folder and edited them perfectly ok. You just cannot do it when you use 'Open with'.

Previously they were tmp files and if you did not use 'Save as' and choose where to save - which is the normal thing to do - then you may lose all your editing.

Either way, if a person wants to switch to edit mode and then save the edited version in a location of choice, then that is their prerogative.
Word / Excel do offer the option to switch on editing in a document that is opened in read-only view, but Thunderbird is not allowing the MS settings to function. That is not acceptable.

Let's be very clear:

  1. The pid folders are not temporary and increase daily.
  2. The files contained in the pid folders are not temporary and may be duplicated many times.
  3. Neither pid folder nor any of it's contents are deleted upon end of session/exit Thunderbird.
  4. Preventing MS products from allowing functions that permit the switching to editable mode is not accetable.
Component: Untriaged → General
OS: Unspecified → All

First, I can confirm that this pid problem started with TB release version 91.6.2 -- several pid folders have been created since that release. I can also confirm that it happens on Windows 7 too.

However...
I see exactly these same kinds of files in the ROOT of the TMP folder which predate the 91.6.2 installation and going back to 2020 !!

And...
I also see "nsemail-nn.eml" files (where nn is one or two digits) from email text written & previewed (in some cases) back in 2020 as well -- along with "nsemail-nn.xxx" (where nn is digits and xxx is a valid extension like jpg or pdf), again going back to 2020. These appear to be attachments which were likewise previewed as part of previewed emails. Very scary! Some of this is private stuff protected elsewhere but otherwise free & visible here. ["Preview" sometimes means me SAVE'ing the file to DRAFT and then perhaps viewing it to get a sense of layout and file size. I can't reproduce this now, but it could be that doing multiple SAVEs might also have caused the files to be created.]

There are also some legitimate temp files created by other programs and not deleted. Some could be relics stranded by various long-ago program crashes, but I know from direct experiment that some were definitely being created but never deleted. Whereas the TB files seem to have just accumulated over time. There are hundreds of these -- and TB doesn't crash anywhere near often enough (if at all) to have abandoned them.

As an end-user with nothing to contribute to the technical discussion (sorry), I would like to add that this bug adversely affects my workflow with Word documents sent as attachments because it prevents me from doing any editing in Word docs unless I first save the file. Previously, I could open an attached Word doc, add highlighting or do other editing, and THEN decide if I actually want to save the file. Sometimes just a quick screen grab of a highlighted sentence is all I need to send back to the original sender, in which case there's no point in saving the file locally. Now, however, that Word functionality is crippled, and the Trust Center settings in Word/Office do nothing to remedy the situation.

I recently stumbled upon these pid folders. In the event this information is useful:

  1. On Linux, the folders are not removed, similar to what the Windows users are reporting, as of 102.3.0. However, this is much less annoying because eventually I will restart my computer and the /tmp folder will be properly cleaned up, unlike Windows. Currently I can see pid folders going back 2 months on this computer, since my last restart, corresponding to various Thunderbird sessions.

  2. Firefox (as of both 91.11.0esr and 103.0) does not have this issue. They create folders called temp-XXXXX with some code not tied to the pid, as soon as they start (even if to a blank tab), and then these are appropriately removed as soon as the browser closes. So presumably the code to deal with this exists, unless there is some difference in underlying mechanism between Thunderbird and Firefox that is not obvious to an end user.

  3. The issues being raised above regarding permissions (editing read-only files, etc.) do not seem to affect Linux, at least in my experience. Everything behaves the same as it always has, which is that the files are opened read-only from /tmp, I can do whatever I want in programs, and I then can save to somewhere permanent.

  4. Obviously files that are opened must be saved locally first. I'm just glad that I don't have to fight Thunderbird to store those (correctly) in/tmp, unlike browsers (including Firefox) that keep trying to dump everything into a "Downloads" folder by default. So if putting up with the folder accumulation for a while is the price of using /tmp vs. the home directory, I'm all for leaving them as-is.

Attachment #9383560 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: