Bug 146642 - FILEOPEN: Detect that the file is in temp directory, and mark it read-only
Summary: FILEOPEN: Detect that the file is in temp directory, and mark it read-only
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
7.2.4.1 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL: https://bugzilla.mozilla.org/show_bug...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-01-07 16:07 UTC by amersdorfer
Modified: 2023-09-04 05:05 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description amersdorfer 2022-01-07 16:07:39 UTC
Description:
Opening Thunderbird attachments are no longer opened as read-only files, but saved automatically in the Temp-Folder of Windows. This could mislead users that they saved the file in the desired location.

Steps to Reproduce:
1. Open an ODS-/ODT-attachment in Thunderbird
2. File opens in Libreoffice
3. File is not marked as read-only, but automatically saved in temp-folder and also marked as saved.

Actual Results:
File in Windows Temp Folder is not set read-only, but saved there.

Expected Results:
File in Windows Temp Folder should be set read-only.


Reproducible: Always


User Profile Reset: Yes



Additional Info:
Version: 7.2.5.2 (x64) / LibreOffice Community
Build ID: 499f9727c189e6ef3471021d6132d4c694f357e5
CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: de-AT (de_AT); UI: de-DE
Calc: threaded

(Bug report tool does not allow to select version 7.2.5)
Comment 1 Mikeyy - L10n HR 2022-01-07 17:36:54 UTC
As I mentioned in connected bug report, I think this is and should stay Thunderbird (Mozilla) issue.

Before version 91.4 when you opened attachment inside Thunderbird, it saved file to C:\Users\Username\AppData\Local\Temp and set Read-only attribute to that file, and then opened it with designated application (in this case LibreOffice).

After TB 91.4 (by bug or intention I'm not sure), Thunderbird no longer sets Read-only attribute after saving it in Temp folder.

It's my opinion that this is best left for Mozilla to fix or not fix, depending if this is bug or feature.
Comment 2 Mike Kaganski 2022-01-07 18:27:37 UTC
Note that Firefox 95.0.2 (64-bit) (updated today) still sets the RO attribute to the files stored to %TEMP% when choosing "Open with". Try e.g with attachment 177347 [details]. OTOH, MS Office does not mark files from %TEMP% as RO, unless they already have that filesystem attribute - try opening an attachment from current Thunderbird in Word.

So maybe really not a LO issue.

See also bug 125093; *maybe* TB could at least mark attachments as received from Internet, if they don't like RO.
Comment 3 Mike Kaganski 2022-01-08 11:10:58 UTC
FTR:

Thunderbird had some bugs related to "opened attachments (using "Open with") are no longer set read only" - long ago: notably https://bugzilla.mozilla.org/show_bug.cgi?id=1095893. That one refers to two other bugs:
https://bugzilla.mozilla.org/show_bug.cgi?id=1074793 - made RO flag depend on "browser.helperApps.deleteTempFileOnExit" advanced setting [1] (search for it in TB's Preferences->General->Config Editor - aka Advanced Preferences);
https://bugzilla.mozilla.org/show_bug.cgi?id=1009465 - that fixed Windows flag [2].

I have checked that on my system, the "deleteTempFileOnExit" is still true, so likely it presumably should work on TB side.

I didn't find anything in TB release notes, nor in their Bugzilla related to "attachment read only" recently. Possibly it just needs filing there, as suggested in comment 1.

However, the related line in TB's  was removed in a fix to https://bugzilla.mozilla.org/show_bug.cgi?id=1649611 [3]. I have commented there.

[1] https://hg.mozilla.org/releases/mozilla-aurora/rev/27edacd145db
[2] https://hg.mozilla.org/releases/mozilla-release/rev/b7d8d79c1ee5
[3] https://hg.mozilla.org/releases/mozilla-release/rev/aadba76932ea3f20967a69813277a637e3bfa025
Comment 4 Mike Kaganski 2022-01-08 11:50:10 UTC
(In reply to Mike Kaganski from comment #3)
> Possibly it just needs filing there, as suggested in comment 1.

https://bugzilla.mozilla.org/show_bug.cgi?id=1749115
Comment 5 amersdorfer 2022-01-10 18:15:42 UTC
(In reply to Mike Kaganski from comment #4)
> (In reply to Mike Kaganski from comment #3)
> > Possibly it just needs filing there, as suggested in comment 1.
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1749115

Thanks for the whole analysis and report to Mozilla!
Comment 6 Buovjaga 2023-03-07 09:49:16 UTC
(In reply to Mike Kaganski from comment #4)
> (In reply to Mike Kaganski from comment #3)
> > Possibly it just needs filing there, as suggested in comment 1.
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1749115

As this is now WORKSFORME, should we close this report?
Comment 7 QA Administrators 2023-09-04 03:13:27 UTC Comment hidden (obsolete)
Comment 8 Mikeyy - L10n HR 2023-09-04 05:05:29 UTC
(In reply to Buovjaga from comment #6)
> (In reply to Mike Kaganski from comment #4)
> > (In reply to Mike Kaganski from comment #3)
> > > Possibly it just needs filing there, as suggested in comment 1.
> > 
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1749115
> 
> As this is now WORKSFORME, should we close this report?

Yes. This works as it should.