In LibreOffice 4.2.0.0.beta2 (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...
There isn't an option to specify the OS release I'm using, it's MacOS X 10.6.8.
Created attachment 90791 [details] Screen capture of behaviour Screen capture video (in QuickTime format) of behaviour.
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...
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.)
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.
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.
*** This bug has been marked as a duplicate of bug 75467 ***