Download it now!
Bug 72722 - Single-clicking on files in the file browser causes their modified dates to be changed (OS X only)
Summary: Single-clicking on files in the file browser causes their modified dates to b...
Status: RESOLVED DUPLICATE of bug 75467
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
(earliest affected)
Hardware: x86-64 (AMD64) Mac OS X (All)
: medium normal
Assignee: Not Assigned
Keywords: regression
Depends on:
Reported: 2013-12-15 02:48 UTC by David H. Gutteridge
Modified: 2014-03-11 05:19 UTC (History)
0 users

See Also:
Crash report or crash signature:

Screen capture of behaviour (2.13 MB, video/quicktime)
2013-12-15 03:12 UTC, David H. Gutteridge

Note You need to log in before you can comment on or make changes to this bug.
Description David H. Gutteridge 2013-12-15 02:48:46 UTC
In LibreOffice (Build ID: 1a27be92e320f97c20d581a69ef1c8b99ea9885d), if I single click on any editable file using the file browser, it immediately updates the modified date of the file, despite the fact that not only have I not modified it, I haven't even opened it yet! This is troublesome for workflows (i.e. mine) where the modified date of the file is significant.

Steps to reproduce:

(1) Click on the file open button.
(2) Navigate to a directory where there's a file you'd like to open.
(3) Single-click on the file. Note that the modification date of the file changes as you do so.
(4) Confirm via the underlying OS tools (e.g. Finder) that the modification date has indeed been updated, even though you did nothing to the file.

This is a regression from 4.1.3 and 4.1.4RC2.

It appears this is caused by LibreOffice adding a MacOS ResourceFork that wasn't previously present in the file. I have no idea why it would be doing that when a user merely clicks on the file name (presumably LibreOffice examines the file immediately and adds extended attributes to it), but if it's by design it's rather ill-advised...
Comment 1 David H. Gutteridge 2013-12-15 02:54:02 UTC
There isn't an option to specify the OS release I'm using, it's MacOS X 10.6.8.
Comment 2 David H. Gutteridge 2013-12-15 03:12:54 UTC
Created attachment 90791 [details]
Screen capture of behaviour

Screen capture video (in QuickTime format) of behaviour.
Comment 3 David H. Gutteridge 2013-12-15 03:13:52 UTC
This only happens on files that haven't already been edited by this release. After it writes the ResourceFork values once, it doesn't update files again this way. Of course, this doesn't take away from the fact it shouldn't be modifying files the user hasn't intended to edit in the first place...
Comment 4 David H. Gutteridge 2013-12-20 03:26:55 UTC
Note that this happens even if a user has the "Read-only" box checked in the file browser, which would be especially counter-intuitive to a typical user.

(Also, since this platform-dependent meta-data would not be preserved on any file system other than an HFS+ volume, this issue would recur with files copied to/from a USB pen drive, over an SMB share, etc.)
Comment 5 David H. Gutteridge 2013-12-21 21:49:02 UTC
My earlier aside about persistence of extended attributes used wrong examples, it seems Mac OS X does preserve them across SMB shares and on MS-DOS file systems by using "hidden" files. It doesn't preserve this particular attribute in zip files, or when files are transferred using FTP or SFTP (though if a file is still present on the originating machine and is copied back, it will still have that attribute maintained from the older copy).

Separately, some software on Mac OS X doesn't preserve this attribute either, e.g. TextEdit does not, so if I create an ODT file in LibreOffice 4.2, then edit it in TextEdit, the attribute is lost.
Comment 6 David H. Gutteridge 2014-01-27 22:41:54 UTC
The new feature that shows recently opened files as thumbnail previews also has the same effect, so when testing 4.2 RC3, it overwrote the modification dates of every file it displayed.

I'm assuming this doesn't affect more recent versions of OS X or someone would've confirmed this by now, but regardless, given this involves meta-data loss, it might be a good idea to include a warning about this in the 4.2 release notes.
Comment 7 David H. Gutteridge 2014-03-11 05:19:06 UTC

*** This bug has been marked as a duplicate of bug 75467 ***