Bug 60290 - FILEOPEN: Opening a file changes the directory's modification date with creation of lockfile
Summary: FILEOPEN: Opening a file changes the directory's modification date with creat...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: Other All
: medium enhancement
Assignee: Not Assigned
Whiteboard: BSA
: 95965 (view as bug list)
Depends on:
Reported: 2013-02-04 18:37 UTC by Rhodes
Modified: 2015-11-29 14:26 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:
Regression By:


Note You need to log in before you can comment on or make changes to this bug.
Description Rhodes 2013-02-04 18:37:15 UTC
Problem description: 
On Mac OS X, opening any file with LibreOffice causes the enclosing directory's modification date to change. This plays havoc with folders organized by date. Am I missing an option, or perhaps invisible lock files I can turn off?

Steps to reproduce:
1. Open any file with LibreOffice
2. Observe that this changes  the enclosing directory's modification date to now.

Current behavior:
The directory's date changes.

Expected behavior:
The directory's date should not change, because nothing (visible) in it has been modified.

Note: I would have tried Ask LibreOffice, but can find no way to log in without a social network membership, which I eschew. This Bugzilla membership doesn't seem to work for that.

Operating System: Mac OS X
Version: release
Comment 1 Urmas 2013-02-05 13:38:04 UTC
It's probably caused by a lockfile. There are already several suggestions about what to do with those files, do they suit you or you have your own?
Comment 2 Rhodes 2013-02-05 18:30:06 UTC
I wouldn't be surprised if it were caused by a lockfile, but I'm looking for definitive documentation on whether they exist and how to turn them off. The only reference I've found is to the script variable SAL_ENABLE_FILE_LOCKING, which I've set to 0 and commented out the export (in LibreOffice.app/Contents/MacOS/gengal) but the directory date still updates. I welcome more information here.
Comment 3 m.a.riosv 2013-02-06 00:12:32 UTC
Hi Rhodes,

when opening there is an option to open in read-only mode, seems that in this way do no create the lock file.
Comment 4 bfoman (inactive) 2013-06-21 12:28:12 UTC
@Roman Eisele
Could you comment as a mac user? Thanks.
Comment 5 Rhodes 2013-06-21 16:35:24 UTC
Yes, opening a file from the Open dialog with the Read-only box checked does not change the enclosing folder modification date, whereas unchecking the Read-only box or opening via drag-and-drop does (LibreOffice So that's a workaround, but it's much less convenient than drag-and-drop, so I'd still like to find a way to turn off the lock file (or whatever), accepting the risk that I might overwrite a parallel file change from a different application. Thanks for your info.
Comment 6 Robinson Tryon (qubit) 2013-12-18 13:05:13 UTC
(In reply to comment #5)
> I'd still like to find a way to turn off the lock file (or whatever),
> accepting the risk that I might overwrite a parallel file change from a
> different application.

This sounds like an enhancement request.

Status: NEW
Severity: Enhancement
Comment 7 jtallerx 2015-11-21 08:42:53 UTC
I am having the same problem on Ubuntu 14.04.
I have directory Temp.
In directory Temp is a file f1.odt.

If I open f1.odt without actually modifying it using LibreOffice, the time stamp of the f1.odt stays same as it should.

But the time stamp of the Temp directory changes.
Is this normal behavior?
My system: 
Ubuntu 14.04.
Comment 8 V Stuart Foote 2015-11-21 14:36:30 UTC
Not advised, but already provided.

Tools -> Options -> Advanced: Expert Configuration 

Search for "UseLocking" which will expose the
/org.openoffice.Office.Common/Misc "UseLocking" stanza, default value is "true"

Edit -> set "false" and OK out.


That edit will record an entry per-user into their profile "registrymodifications.xcu" configuration file.

Can revert from Expert Configuration or by editing the registrymodifications.xcu file directly. Once set remains available in registry to manually toggle between true|false.

This suppresses creation of the lock file in the folder where the document resides. Opening document via dialog in read-only mode also does not create the lock file.
Comment 9 V Stuart Foote 2015-11-21 14:36:56 UTC
*** Bug 95965 has been marked as a duplicate of this bug. ***
Comment 10 jtallerx 2015-11-29 07:22:42 UTC
Thanks to V Stuart Foote.
Indeed the setting "UseLocking" to false fixes it nicely.
Comment 11 V Stuart Foote 2015-11-29 14:26:33 UTC
While this works reliably, YMMV. It was implemented for performing unit testing during development in 2012. Work last year on Expert Configuration exposed it conveniently as noted comment 8.

Commit on 2012-01-13

@Markus, how "dangerous" is it for folks to work without lockfile, and is this a "feature" we should expose in the UI outside Expert Configuration?