Bug 150118 - Different behavior opening files having read-only permissions on Windows vs. Linux
Summary: Different behavior opening files having read-only permissions on Windows vs. ...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Balázs Varga
URL:
Whiteboard: target:26.2.0
Keywords:
Depends on:
Blocks: Read-Only
  Show dependency treegraph
 
Reported: 2022-07-23 20:16 UTC by Mike Kaganski
Modified: 2025-10-11 15:28 UTC (History)
4 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 Mike Kaganski 2022-07-23 20:16:05 UTC
Open a file that has no read-only *attribute*, but that is located in a directory that has read-only permissions for the given user. For example, use a document from share:

on Windows, it is at C:\Program Files\LibreOffice\share\template\shellnew
on Ubuntu, it is at opt/libreoffice7.3/share/template/common/internal

Both locations on both OSes are non-writable for non-elevated user. Or an empty document could be created in such a location as a root/admin for testing.

Trying to open a document from such a document in LibreOffice on Ubuntu opens the document in read-only mode (with an infobar), without any dialogs.

Trying to open a document from such a document in LibreOffice on Windows first opens a dialog:

> Document file 'soffice.odt' is locked for editing by:
> 
> Unknown User
> 
> Open document read-only or open a copy of the document for editing.
> Select Notify to open read-only and get notified when the document becomes editable.

On Windows, if the document in such a location *in addition* gets a read-only *file attribute*, like running 'attrib +R "C:\Program Files\LibreOffice\share\template\shellnew\soffice.odt"' as admin, it starts opening the same way as on Linux: without any dialog, right into read-only mode with an infobar.

It is likely because on Linux, the permissions are connected to file attributes, while on Windows, ACL is unrelated to attributes; but the difference in behavior in conceptually similar (same) situations is confusing and inconvenient. E.g., it results in inconvenience (unneeded dialogs) when opening files from read-only locations, like in https://ask.libreoffice.org/t/read-only-is-on-purpose-but-libreoffice-always-ask-what-i-want-to-do/79795.
Comment 1 Vladimir Sokolinskiy 2022-07-26 12:11:12 UTC
Repro.
Version: 7.3.4.2 (x64) / LibreOffice Community
Build ID: 728fec16bd5f605073805c3c9e7c4212a0120dc5
CPU threads: 6; OS: Windows 10.0 Build 19044; UI render: default; VCL: win
Locale: ru-RU (ru_RU); UI: en-US
Calc: threaded
Comment 2 Commit Notification 2025-10-10 14:24:40 UTC
Balazs Varga committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/1b5d039d8b5861b5ea21ef00ff521c6e2565105f

tdf#150118 check file permissions on windows if have no readonly

It will be available in 26.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 3 Commit Notification 2025-10-11 15:28:03 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/1a4f72f03b1bd49d486e52135e78971242fae649

tdf#150118: fix call to AccessCheck

It will be available in 26.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.