Bug 75467 - OS X integration: selecting a file in Open File dialog or merely viewing a folder in Save File dialog adds resource fork, changes size and mod date (10.6/10.7)
Summary: OS X integration: selecting a file in Open File dialog or merely viewing a fo...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
(earliest affected) Master
Hardware: All macOS (All)
: highest major
Assignee: Peter Nowee
Whiteboard: target:4.3.6 target:4.3.7
Keywords: bibisected, bisected, regression
: 72722 77783 80409 80862 (view as bug list)
Depends on:
Blocks: mab4.3
  Show dependency treegraph
Reported: 2014-02-24 20:42 UTC by Ken
Modified: 2015-12-17 07:48 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:

zip of blank.doc after LO added resource fork (1.77 KB, application/zip)
2014-03-05 17:25 UTC, Ken
bibisect log (2.74 KB, text/plain)
2015-01-16 16:28 UTC, Peter Nowee
bibisect visualize: Shows source commits between good and bad version (6.21 KB, text/plain)
2015-01-16 16:45 UTC, Peter Nowee
Commit 7aa4291 responsible for bug in Save as dialog (2.14 KB, text/plain)
2015-01-19 14:15 UTC, Peter Nowee
Commit aa539f6 responsible for bug in Open dialog (4.54 KB, text/plain)
2015-01-19 14:16 UTC, Peter Nowee

Note You need to log in before you can comment on or make changes to this bug.
Description Ken 2014-02-24 20:42:45 UTC
Upon opening some .doc files, LibreOffice ( Mac 32-bit) makes the original files bigger and changes their modification dates.  The files can be downloaded from here, "Press release (DOC) / EN":


Now I am afraid to allow LibreOffice open any files without either locking them or making copies first.
Comment 1 Jean-Baptiste Faure 2014-03-01 21:51:13 UTC
I do not understand what you mean. LibreOffice does not save a modified document if you do not ask for that.

Please could you describe step by step what you do to reproduce the problem ?

Best regards. JBF
Comment 2 Ken 2014-03-01 22:32:44 UTC
It's exactly as it sounds:

1.  Observe that before opening, the OS X Finder Get Info reports that downloaded file "LOUIS MOINET_EN.doc" has size "36,864 bytes" and modification date "Thursday, March 14, 2013 9:39AM".

2.  Double-click file "LOUIS MOINET_EN.doc", thereby causing OS X to open the file in LibreOffice.  (Leave it open and do nothing else.)

3.  Observe that the OS X Finder Get Info now reports that file "LOUIS MOINET_EN.doc" has size "37,150 bytes" and modification date "Today 5:24PM" (or whatever your current time is).
Comment 3 Jean-Baptiste Faure 2014-03-02 06:43:38 UTC
Ah ok, and what happen when you close the file without saving it ? And when you reopen it, did it have been modified ?
If the file has not been modified, I guess that the problem is on the Finder side not on the LibreOffice side.

When a file in opened in LibreOffice you can check its properties from LibreOffice: menu File > Properties. Does LibreOffice find the same thing than Finder ?

Best regards. JBF
Comment 4 Ken 2014-03-02 17:38:28 UTC
> what happen when you close the file without saving it ?

The properties remain the first-open-modified "37,150 bytes" and "Today 5:24PM".  I.e., it neither reverted back to original, nor was changed again after the first change.

> And when you reopen it, did it have been modified ?

The size remains the first-open-modified "37,150 bytes" and "Today 5:24PM".  I.e., opening it subsequent times never changes it again after the first open changes it.

> If the file has not been modified, I guess that the problem is on the Finder side not on the LibreOffice side.

But, the file properties do not change when performing Finder operations Get Info, Duplicate, Compress, Quick Look, or Open With TextEdit, so the problem is demonstrably unique to Open With LibreOffice....

> When a file in opened in LibreOffice you can check its properties from LibreOffice: menu File > Properties. Does LibreOffice find the same thing than Finder ?

Interestingly, no!  Even though the Finder Get Info shows "37,150 bytes" and "Today 5:24PM", LibreOffice Properties General shows the original "36,864 Bytes" and "03/14/2013, 02:39:00".  Going further, the OS X command line ls -l shows the original size, the new modification date, and the presence of extended attributes....

Also interestingly, a new discovery:  if I open LibreOffice standalone, choose Open File, and then in the Open dialog window, merely *select* (highlight) the filename without proceeding to open it, the operating system file properties change immediately!

So, it appears that LibreOffice causes OS X to add 286 bytes to the file's extended attributes and update the modification date, even before actually opening the file.
Comment 5 Ken 2014-03-02 17:53:33 UTC
Aha:  the 286 bytes is an OS X resource fork.  LibreOffice is causing a resource fork to be added to a file prior to saving.  It should not do that.
Comment 6 Jean-Baptiste Faure 2014-03-03 05:32:47 UTC
Thank you very much for your investigations.

Set status back to unconfirmed. Waiting for a independent confirmation (I do not use MacOS).

Best regards. JBF
Comment 7 Jorendc 2014-03-03 09:05:41 UTC
Mmh, I fail to reproduce the fact 'opening a file (either double click in Finder or open it via LibreOffice File > Open) result in a bigger and changed file'.

Tested using Mac OSX 10.9 with LibreOffice Version:
Build ID: 3be8cda0bddd8e430d8cda1ebfd581265cca5a0f

@Ken: if you go to LibreOffice > Preferences > LibreOffice > General
Is the option 'Allow to save the document even when the document is not modified' checked? There are also some other interesting and maybe related options in Load/Save > General.
Does (un)selecting one of this options solve this behavior?

Kind regards,
Comment 8 Ken 2014-03-03 18:00:55 UTC
'Allow to save the document even when the document is not modified' is not checked.  I also tried clearing the 2 Load/Save > Load options and restarting, no improvment.

I verified that it happens with any .doc file which has no resource fork:

1.  Create a blank Writer Microsoft Word 97 document, for example "blank.doc", and close it.

2.  Delete the resource fork, for example using the command:

    xattr -d com.apple.ResourceFork blank.doc 

4.  Observe the size and modification date of the file using the command

    ls -apl@

    For example:

    -rw-r--r--   1 user1  staff   9216 Mar  3 12:50 blank.doc

    and also the size using the Finder Get Info, for example:

    Size: 12 KB on disk (9,216 bytes)

5.  In LibreOffice > Open File, select (highlight) "blank.doc" (do not open it).

6.  Observe with ls -apl@ and Finder Get Info that the file now suddenly has a brand new resource fork, modification date, and Finder Get Info size, for example:

    -rw-r--r--@  1 user1  staff   9216 Mar  3 12:51 blank.doc
	    com.apple.ResourceFork	  286 

    Size: 16 KB on disk (9,502 bytes)
Comment 9 osnola 2014-03-04 08:57:38 UTC
I also failed to reproduce this behavior with OSX 10.9.2 and LibreOffice 4.3 (home compiled). But it can interesting to see what have been added in the resource fork, 
- either by using terminal and typing:
DeRez blank.doc
if you have installed the developer tools 
- or by first zipping the file blank.doc (to conserve the resource fork) and then attaching it.

- if this happens before opening the file in LibreOffice, I guess that this is not LibreOffice which happens this resource fork but more probably a Finder's extension...
- if the size of resource fork is 286, it probably only contains one short resource ; i.e. even if it can be shortened, the header size of a resource fork is often 256 bytes, so this let 30 bytes for the resource map (~20bytes if it contains one resource) and the resource data(maybe 10bytes).
Comment 10 Ken 2014-03-04 15:18:26 UTC
No Developer Tools installed, but here is the printable content of the 286-byte resource fork LibreOffice caused to be added to a forkless blank.doc file:

–œ‡°±·;˛ˇ	˛ˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇ˝ˇˇˇˇˇˇˇ˛ˇˇˇ	

˛ˇˇˇ˛ˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇRoot Entryˇˇˇˇˇˇˇˇˇˇˇˇ˛ˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇ˛ˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇ˛ˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇ˛ˇˇˇ˛ˇˇˇ˛ˇˇˇ	

˛ˇˇˇ˛ˇˇˇ !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUV˛ˇˇˇX˛ˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇˇ˛ˇ
ˇˇˇˇ	¿FMicrosoft Word-Dokument
[ZÒˇZNormal1$*$3B*OJQJCJmH	sH	KHPJnHtH^JaJ_H9F˛FHeading
§§x$OJQJCJPJ^JaJ4B4	Text Bodyd §§å/List<""<Caption
§x§x$CJ6aJ]"˛2"Index$ˇˇˇˇPGêTimes New Roman5êSymbol3&êArialiêLiberation SerifTimes New RomanIêArial Unicode MSS&êLiberation SansArialBç≈h%#'Éê' 0 0IJˇ‡ÖüÚ˘Oh´ë+'≥Ÿ0|8	@
pÈ˝0@@@fiòZ=7œ@Ï•M 	ø0Caolan80	$ˇˇˇˇˇˇàäääû™◊æ∂ïb¬∂Ÿ
˝"∞–/ ∞‡=!∞n"∞n#ên$ên3P(20˛ˇ’Õ’ú.ìó+,˘ÆD’Õ’ú.ìó+,˘Æ\È˝È˝Root Entryˇˇˇˇˇˇˇˇ	¿F@CompObjˇˇˇˇjOle
Comment 11 Ken 2014-03-04 15:41:03 UTC

While the addition of the resource fork does happen before actually executing a file-open in LibreOffice, it only happens after running LibreOffice, opening the Open dialog, and selecting a file in that dialog.  Since this does not happen when selecting files in other applications' Open dialogs, there must be something different about how LibreOffice's OS X package is interacting with the operating system.

I don't know what osnoal means by "a Finder's extension"; I am not even convinced that the Finder application is involved.
Comment 12 Ken 2014-03-04 16:13:37 UTC
Oh...also:  OS X 10.6.8.  Could be a version-specific behavior, I suppose.
Comment 13 osnola 2014-03-05 09:20:04 UTC
(In reply to comment #10)
Can you send me the modified blank.doc file by email ? Ie. without the original resource fork, it is really difficult to know what has been stored inside....
Comment 14 Urmas 2014-03-05 11:59:41 UTC
Ken, this is not the resource fork. Use the zip archive as you've been told.
Comment 15 Ken 2014-03-05 17:23:53 UTC
osnola, the data fork has not been modified, only the operating system file properties have been modified as a result of the addition of the resource fork.  It is the resource fork which should not have been added and the file properties which should not have been changed.

Urmas, you are right:  when I selected "Open other fork" in OxED, something must have gone wrong, and I didn't notice.  However, that was an honest mistake, and I neither deserve nor respond positively to rudeness such as "do as you've been told".

The actual resource fork is mostly nulls.  I will try adding blank.doc.zip as an attachment.
Comment 16 Ken 2014-03-05 17:25:22 UTC
Created attachment 95178 [details]
zip of blank.doc after LO added resource fork
Comment 17 osnola 2014-03-06 08:03:44 UTC
(In reply to comment #16)
> Created attachment 95178 [details]
> zip of blank.doc after LO added resource fork
the resource fork does exists but contains no data. Maybe, somewhere a call to the deprecated API FSpOpenRF is done with a bad argument ( or less probably a call setxattr: see https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man2/setxattr.2.html )

More precisely, the content of the resource fork is:
000000 [Header:]0000010000000100000000000000001e
000010 000000000000000000000000000000...
000100 [Entries(RSRCMap):N=0]0000010000000100000000000000001e0000000000000000001c001effff
ie. it begins by a valid header and then we find at the position 256 a resource map which contains no entry...
Comment 18 David H. Gutteridge 2014-03-11 04:04:15 UTC
This is a duplicate of bug 72722, which I reported back in December. One of them should be closed. My bug report confirms this problem behaviour, it has a screen capture video showing the issue for anyone who can play QuickTime video. I suspect it only occurs on older Mac OS X releases. (Obviously on 10.6, not sure about 10.7.)
Comment 19 David H. Gutteridge 2014-03-11 05:05:23 UTC
Changing software version back to beta 2, the earliest known version I tested against that exhibited this problem. (I'd wager that beta 1 and alpha versions likely have it to0, mind you.)
Comment 20 David H. Gutteridge 2014-03-11 05:19:06 UTC
*** Bug 72722 has been marked as a duplicate of this bug. ***
Comment 21 David H. Gutteridge 2014-03-11 05:22:43 UTC
I've closed my bug as a duplicate, since this one seems to be getting some attention. (It's unfortunate that Ken had to spend time retracing my steps, but I'll say no more...)

Merging additional information from my bug report:

- This happens even if a user has the "Read-only" box checked in the file browser.
- The new start screen that shows recently opened files as thumbnail previews also has the same effect; in my testing, it overwrote the modification dates of every file it displayed.

In other words, if LibreOffice becomes aware of a file (before it actually does anything to open it, if that's even requested), it modifies it by adding a spurious ResourceFork, assuming it hasn't done so already.

I'd suggested someone add a warning to the known bugs list on release notes, which would still be a good idea. (I have to say the release notes appearing on the site now are out of date and very incomplete compared to what was published on the LibreOffice Wiki which used to be linked...)
Comment 22 Maxim Monastirsky 2014-05-06 19:36:17 UTC
*** Bug 77783 has been marked as a duplicate of this bug. ***
Comment 23 David H. Gutteridge 2014-05-06 23:16:07 UTC
The LibreOffice 4.1 series does not exhibit this problem, so anyone concerned about this bug is best off using 4.1.6 for now. (I expect there may be a few more users tripping over this now that OpenOffice doesn't support Snow Leopard.)

Bug 77783 seems to confirm that Lion is also affected.
Comment 24 Ken 2014-05-07 15:15:27 UTC
Confirming David's comment 21, when I saved a new spreadsheet file into a directory, it added empty resource forks and changed the file system modification dates of *every* forkless file in the directory, regardless of type.  Which renders 4.2 a critical hazard in my environment, and forces me back to 4.1.6 as well.  I wish there was something I could do to help get it fixed, but I have zero OS X API programming experience.
Comment 25 Serge Faraut 2014-06-13 07:56:30 UTC
Confirming the bug.
Tried latest 4.2 version (, latest 4.3 beta version (libreoffice-4-3~2014-06-10_07.13.43_LibreOfficeDev_4.3.0.0.beta2_MacOS_x86) and all various options (even the option "LibreOffice/Open-Save dialogs/Use LibreOffice dialogs to not use Mac OS X native dialogs).
The results are the same: all selected files in the open dialog are modified!

The Mac OSX version I (still) use is 10.6.8. I actually haven't yet tried with more recent versions of OS X, but I will shortly for Moutain Lion (10.8) and will inform you.
Comment 26 Jorendc 2014-07-03 20:27:34 UTC
*** Bug 80862 has been marked as a duplicate of this bug. ***
Comment 27 Adriano Belletti 2014-07-04 06:58:40 UTC
I reported the same bug in feedback 80862, detected actually on LO and MacOS 10.6.8.

I think the importance of this bug has to be set to more important level, because it causes the messing up of the files chronology on the user's computer.
It's a big problem!
I'll return to 4.1 versions, or to OO

Lots of Mac user still use MacOS 10.6.8 (it has lots of feature lost with 10.7 and above), and OO with 4.1 version has discontinued the 10.6.x support.
Comment 28 David H. Gutteridge 2014-07-04 08:47:22 UTC
I've added the "regression" keyword, since it's established 4.1 and earlier don't exhibit this problem. I'm not sure if this should be a MAB for 4.2 or not as well (or if that's overkill)?
Comment 29 declan_moriarty 2014-07-18 09:06:08 UTC
I can confirm it happens on OS X 10.7.3.  .doc files opened, but not edited, have the modification dates changed to today and the time to now.  I also had a whole directory of files this happened to.  The files do have extended attribates with the @ symbol in an ls -l listing.
Comment 30 declan_moriarty 2014-07-19 10:57:44 UTC
I have opened a file today in a directory full of .doc files.  All the files listed in the directory before the file I wanted to open have had the time changed to today and the time set to when I opened the one file.  The directory was listed in Modification Date order in finder with the Modification Date showing.  This is a major bug and I will be degrading to the stable version of LibreOffice until this is fixed.

OS: OS X 10.7.3.

LibreOffice: 4.2.5
Comment 31 David H. Gutteridge 2014-07-19 20:33:09 UTC
I've added this to the 4.2 MAB bug list. Following the LO "Prioritizing Bugs Flowchart", I'm also bumping this to "critical", since it involves data loss. (I've left it at "medium" because I don't know if this affects that many users. It doesn't seem to affect newer versions of Mac OS X.)
Comment 32 Joel Madero 2014-07-19 20:47:13 UTC
This is not a critical bug (that's for bugs that literally are losing real data inside the file and will substantially impair the ability for a user to create and maintain work) meta data is not the same - changing to major.

Also for MAB should be set to highest - went ahead and did this
Comment 33 David H. Gutteridge 2014-07-19 21:52:56 UTC
I disagree. In this case, I feel the distinction between meta-data and data is academic. This is a bug that will indeed "substantially impair the ability for a user to create and maintain work": if file modification dates are corrupted, fundamental workflows can be broken. Data about data can be as important as the content itself. The fact that multiple respondents are reverting to the 4.1 series to get their work done proves my point.

(Having said that, I'm not going to tinker with the bug further. I recognize you're a significant member of the LO QA team trying to triage hundreds of bugs, and I'm just complaining loudly about something that affects me personally.)
Comment 34 Joel Madero 2014-07-19 21:59:52 UTC
:) Thanks for respecting that and not getting in some war over the severity :) Feel free to ping the QA list if you want a second opinion.

That being said - it's on the MAB list and set as highest with "regression" in keyword, so regardless of if it's major or critical, it's getting the same look by expert developers
Comment 35 haim kilov 2014-07-29 20:14:15 UTC
I agree that this is a major bug. It did impair some of my work. OS 10.6.8.
Comment 36 Adriano Belletti 2014-08-25 09:23:26 UTC
*** Bug 80409 has been marked as a duplicate of this bug. ***
Comment 37 Anastasius 2014-10-28 20:05:12 UTC
Still present in LO 4.3.2.
File dialogs (both open and save dialogs) modify the ALL file modification dates in that directory to the current date. This happens at a rate of about 5 files/second, as long as the dialog is open, even if one cancels the dialog!

For me, this is an absolutely critical issue - I need the file modification dates and LO has destroyed a lot of them!
Comment 38 tommy27 2014-10-28 20:25:53 UTC
do not put a bug in multiple MAB lists.
it already belongs to the MAB 4.2 list.
Comment 39 Alex Thurgood 2014-10-28 21:59:32 UTC
Has anyone reproduced this with 10.8, 10.9 or 10.10 ?

There is a similar bug report that I encountered recently, but can't remember the number now, where the person reporting had this problem on 10.6.8, but I was unable to reproduce on 10.9 or 10.10.
Comment 40 Anastasius 2014-11-19 09:27:43 UTC
(In reply to tommy27 from comment #38)
> @Anastasius 
> do not put a bug in multiple MAB lists it already belongs to the MAB 4.2 list.

Incredible. This bug is corrupting whole directories, thousands of files on my computer and I have lost already much work because sync/backup was overwriting new with old versions due to that bug, and I can't find related files (having the same creation dates) any more. And then people care whether the report appears in one or two MAB lists and discuss whether it's "critical" or not, instead of fixing it! There is absolutely no use developing any new features as long as this is not fixed.

4.1.6 is not available any more (and I don't have a backup of it); so I will have to move to Apache OO to prevent further havoc.
Comment 41 Alex Thurgood 2014-11-19 10:13:39 UTC
This is unlikely to be fixed :

- the problem does not appear to manifest itself on OSX 10.8, 10.9 or 10.10.

- 10.6 is no longer the baseline SDK for 64bit releases, rather the baseline sdk is 10.8

- no developer resources are around to fix bugs for OS versions that are already no longer officially supported by Apple (update support)

Setting as wontfix
Comment 42 Adriano Belletti 2014-11-19 13:20:37 UTC
In download page you MUST include LO 4.1.6 as the final version for MacOS 10.6.8 (and perhaps 10.7 too)
Comment 43 tommy27 2014-11-19 14:57:32 UTC
in the meantime take a look at this link:
Comment 44 Ken 2014-11-19 16:53:24 UTC
Then LO 4.2+ must be made to refuse to run on OS X 10.7-, otherwise LO will continue to harm users with older machines/OSes.
Comment 45 Alex Thurgood 2014-11-19 18:00:14 UTC
Imposing obligations on unavailable volunteer OSX developer resources is unlikely to get any takers either.

Simply put, unless someone has the means to fix it themselves, or pay a developer to do it either directly or via a support contract, then this is never going to happen. Ranting about what should or shoudn't be done won't change that. 

This is the same for virtually all of the bugs that are OSX specific - I too have my pet hates, but as I'm unable to either fix them myself or pay someone the required appropriate amount of qualified programmer time to do it for me, I'll make do. If that means dumping LO in favour of another program that does what I need, then so be it.
Comment 46 Ken 2014-11-19 18:27:45 UTC
Alex, the obligation of software developers to prevent their software from harming users is not imposed by individuals, it is imposed by human decency.  And I am confident that the LO team is up to the trivial task of adding a LSMinimumSystemVersion key to the Info.plist text file in each 4.2+ OS X application bundle to prevent such harm.
Comment 47 Adriano Belletti 2014-11-19 20:11:39 UTC
Alex, there's no need of a programmer to put this line in the download web page:
"Install 4.1.6 version on MacOS X 10.6.8 and previous : LINK"
Comment 48 Peter Nowee 2015-01-06 13:49:17 UTC
First of all, I can confirm this terribly annoying bug (LibreOffice on Mac OS X 10.7.5). Simply even selecting a file in the File Open dialog of LibreOffice changes its Date Modified. For me personally, this is not only a big inconvenience, but also makes rsync automatically re-backup old files all the time, because they have changed.

@Alex: I do not agree with your decision to mark this bug as RESOLVED WONTFIX. This is an open source project, right? So how do you know nobody will pick up this bug? Someone owning the right hardware might find honor in fixing a major bug like this. A "WONTFIX" label is discouraging for potential developers. It gives the impression that any patches won't be accepted. So I think it should stay open, at least until the end of support for OS X 10.6/10.7, so that any willing and able bug fixer can spot it and trust that a working patch will be accepted.

Would it not be nice if the 4.3-series could go into history as the last good working version for OS X 10.6 / 10.7, without a big asterisk next to it saying: Use at own risk; messes up unrelated files on your system!

I hope you can reconsider.


The software and hardware prerequisites for installing on a Apple Mac OS X computer are as follows:
- Mac OS X 10.6 (Snow Leopard) or higher;
- The next release series (4.4) will require OS X 10.8+; Support for OS X 10.6/10.7 will end when LibreOffice 4.3 is retired on May 27, 2015.
Comment 49 Peter Nowee 2015-01-16 16:28:10 UTC
Created attachment 112354 [details]
bibisect log
Comment 50 Peter Nowee 2015-01-16 16:45:19 UTC
Created attachment 112355 [details]
bibisect visualize: Shows source commits between good and bad version

I bibisected this bug. Likely candidate source commits of bug introduction:

c22acb4 Don't use deprecated API
7aa4291 WaE: 'FSResolveAliasFile' is deprecated: first deprecated in OS X 10.8
e738820 WaE: 'UpdateSystemActivity' is deprecated: first deprecated in OS X 10.8

These were changes in fpicker/source/aqua and/or vcl/aqua/source/window/salframe.cxx by Tor Lillqvist on June 16 and 18, 2013.

I emailed Tor for help, but he said he has no interest to spend his own time on it if it indeed is something that happens only for 10.6 or 10.7

Unfortunately, I'm not much of a developer, so I don't know how to go from here. I prepared my laptop (OS X 10.7.5) with XCode 4.6.3, SDK 10.7.5, Command Line Tools, autoconf, automake, ccache and a git clone of LO core. I successfully built LO on it. Anyone who thinks he knows how to fix this bug can send me suggestions and then I can make a test build. I'm also visiting FOSDEM later this month in Brussels and can take my laptop then.

Comment 51 tommy27 2015-01-17 06:16:53 UTC
let's remove this from the mab4.2 list which is closed after 4.2.x end of life and let's keep it under the mab4.3 list

I've seen you put yourself under "Assigned to"

that field means that you are going to fix it yourself.

according to your latest comment it seems that you are not able to do it alone but you need help from another developer, right?
Comment 52 Peter Nowee 2015-01-17 07:20:26 UTC
@tommy27 : Yes, that's right. I assigned it to myself because I don't agree with this bug being marked RESOLVED/WONTFIX. I can understand that people who are running Mac OS 10.8+ have no incentive to fix this bug, but that does not resolve it for users of 10.6 and 10.7, for who it is a serious deal breaker. So I took this bug mainly because nobody else will.

I am currently trying to manually source-bisect the bug, but this is going very slow (each build takes 5 to 8 hours and I often run into build errors). If I succeed to pinpoint the offensive code, I will probably ask experienced Mac OS X developers to comment on what may be wrong with it. If nobody is available within the LO community itself, I was planning on asking on a Mac OS X developer forum or something.

So, yes, I am doing what I can, but I could really use some help.
Comment 53 Peter Nowee 2015-01-19 14:15:31 UTC
Created attachment 112472 [details]
Commit 7aa4291 responsible for bug in Save as dialog
Comment 54 Peter Nowee 2015-01-19 14:16:51 UTC
Created attachment 112473 [details]
Commit aa539f6 responsible for bug in Open dialog
Comment 55 Peter Nowee 2015-01-19 14:18:14 UTC
I manually bisected and narrowed the problem down to the following two commits:

- 7aa4291 introduced the bug that changes the Modified Date of files selected in the File, Open.. dialog.
- aa539f6 introduced the bug that changes the Modified Dates of all(*) files shown in the File, Save as.. dialog.

Both commits were made by Tor Lillqvist on Jun 16, 2013.

I am currently trying to narrow down the problem to the specific code within the commits. Any help would be appreciated.

*) In the Save As dialog, files of the same type as selected in the "File Type" drop down will not be affected until another type is selected.

Comment 56 Peter Nowee 2015-01-20 05:31:43 UTC
I picked apart the commits and found the problems are caused by calling CFURLCreateBookmarkDataFromFile:

Offensive line from 7aa4291 (Open dialog bug)

  CFDataRef rBookmark = CFURLCreateBookmarkDataFromFile( NULL, rUrl, &rError );

Offensive line from aa539f6 (Save dialog bug)

  CFDataRef cfbookmark = CFURLCreateBookmarkDataFromFile( NULL, cfurl, &cferror );

A search for CFURLCreateBookmarkDataFromFile turned up http://www.opensource.apple.com/source/CF/CF-635/CFURL.h, which says that this function overwrites files by adding bookmark and alias data.

But why does this not cause any problems in any other applications then? Could it be this only goes wrong in 32-bit?

Could someone running Mac OS 10.8 or higher try to reproduce this bug with the 32-bit (x86, not x86_64) build? See comment 8 for steps to reproduce. The bug is still present in LO 4.3.6 RC1. The 32-bit version can be downloaded here:

Comment 57 Adriano Belletti 2015-01-20 07:37:32 UTC
Hi @Peter, unfortunately I don't know how to help you, but your commitment is commendable.
The only thing I know is that the version on MacOS 10.6.8 does not have this bug.
Thanks a lot!!!
Comment 58 David H. Gutteridge 2015-01-21 00:46:56 UTC
>A search for CFURLCreateBookmarkDataFromFile turned up >http://www.opensource.apple.com/source/CF/CF-635/CFURL.h,
>which says that this function overwrites files by adding
>bookmark and alias data.

Peter, I think you're reading the wrong function description, the description of CFURLWriteBookmarkDataToFile says that, but not CFURLCreateBookmarkDataFromFile. (The documentation is above each function definition, not below.) Unless we're somehow looking at different versions of the same...

From looking at the code, I can't understand why it would be causing the files to be modified, but if you're saying that you backed out those two specific change sets and the problem went away, then this must be the cause somehow. (Perhaps a bug in Apple's implementation in older OS X releases.)

If that's indeed the case, the simplest solution would be to back out those two change sets in the 4.3 branch only (leaving them as-is in newer branches which don't claim to support OS X 10.6 or 10.7 anyway). If I've read Apple's documentation correctly, up through OS X 10.10, the old functions that were replaced are deprecated, not removed, so while this will cause a deprecation warning during compilation (I assume), it shouldn't have any adverse affects on users running 10.8+. (Someone would have to test this to confirm.)
Comment 59 Peter Nowee 2015-01-23 08:39:07 UTC
@David: You're right, I was looking at the wrong description. Indeed CFURLCreateBookmarkDataFromFile function should not write any data. Yet, it still seems to do exactly that in this particular situation.

Further developments:

On IRC, Alex Thurgood tested a recent 32-bit of LO 4.3 with Mac OS 10.8+ and the bugs did not appear. This shows that it is really a 10.6/10.7-specific problem, not a 32-bit problem.

In February 2014, in his work to port current versions of LO to PowerPC Macs, Douglas Mencken brought back the code that was removed in June 2013, for use on Mac OS X < 10.6 only.

Extending the use of that code to Mac OS X 10.6 and 10.7 makes this bug disappear. This morning, I submitted a patch to that effect for review. I'm hoping it will be included in 4.3.6.

More details: https://gerrit.libreoffice.org/#/c/14123/
Comment 60 Commit Notification 2015-01-23 11:58:25 UTC
Peter Nowee committed a patch related to this issue.
It has been pushed to "libreoffice-4-3-6":


fdo#75467 extend Carbon API alias resolve from OS X 10.5 to 10.7

It will be available in 4.3.6.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
Affected users are encouraged to test the fix and report feedback.
Comment 61 Commit Notification 2015-01-23 12:01:09 UTC
Peter Nowee committed a patch related to this issue.
It has been pushed to "libreoffice-4-3":


fdo#75467 extend Carbon API alias resolve from OS X 10.5 to 10.7

It will be available in 4.3.7.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
Affected users are encouraged to test the fix and report feedback.
Comment 62 tommy27 2015-01-23 12:30:23 UTC
congrats for keep tryng and ultimately fixing this old MAB.
welcome on board to the LibO development team  :-)
Comment 63 Peter Nowee 2015-01-23 13:01:25 UTC
@tommy27 Thanks :) and thanks to you and all the others commenting on this bug for your help.
Comment 64 David H. Gutteridge 2015-02-11 00:35:19 UTC
Confirming the fix works for me in 4.3.6 RC2 in my original environment (Mac OS X 10.6.8). Thanks for this!
Comment 65 Robinson Tryon (qubit) 2015-12-17 07:48:46 UTC Comment hidden (obsolete)