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

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).

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

> 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.

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.

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

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: 4.2.2.1
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,
Joren

'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)

Hello,
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.

Note: 
- 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).

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
MSWordDocWord.Document.8Ù9≤q
[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	@
LXd
pÈ˝0@@@fiòZ=7œ@Ï•M 	ø0Caolan80	$ˇˇˇˇˇˇàäääû™◊æ∂ïb¬∂Ÿ
˝"∞–/ ∞‡=!∞n"∞n#ên$ên3P(20˛ˇ’Õ’ú.ìó+,˘ÆD’Õ’ú.ìó+,˘Æ\È˝È˝Root Entryˇˇˇˇˇˇˇˇ	¿F@CompObjˇˇˇˇjOle
ˇˇˇˇˇˇˇˇ1Tableˇˇˇˇˇˇˇˇˇˇˇˇ˜SummaryInformation(ˇˇˇˇ¨WordDocumentˇˇˇˇˇˇˇˇˇˇˇˇ$DocumentSummaryInformation8ˇˇˇˇˇˇˇˇˇˇˇˇWtˇˇˇˇˇˇˇˇˇˇˇˇ˛ˇˇˇ

Continuing...

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.

Oh...also:  OS X 10.6.8.  Could be a version-specific behavior, I suppose.

(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....

Ken, this is not the resource fork. Use the zip archive as you've been told.

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.

Created attachment 95178 [details]
zip of blank.doc after LO added resource fork

Hello,
(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
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...

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.)

Changing software version back to 4.2.0.0 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.)

*** Bug 72722 has been marked as a duplicate of this bug. ***

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...)

*** Bug 77783 has been marked as a duplicate of this bug. ***

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.

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.

Confirming the bug.
Tried latest 4.2 version (4.2.4.2), 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.

*** Bug 80862 has been marked as a duplicate of this bug. ***

I reported the same bug in feedback 80862, detected actually on LO 4.2.5.2 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.

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)?

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.

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

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.)

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

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.)

:) 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

I agree that this is a major bug. It did impair some of my work. OS 10.6.8.

*** Bug 80409 has been marked as a duplicate of this bug. ***

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!

@Anastasius 
do not put a bug in multiple MAB lists.
it already belongs to the MAB 4.2 list.

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.

(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.

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

In download page you MUST include LO 4.1.6 as the final version for MacOS 10.6.8 (and perhaps 10.7 too)

in the meantime take a look at this link:
http://downloadarchive.documentfoundation.org/libreoffice/old/

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.

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.

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.

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"

First of all, I can confirm this terribly annoying bug (LibreOffice 4.3.5.2 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.

Thanks,
Peter

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;
..
and:
- 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.
http://www.libreoffice.org/get-help/system-requirements/

Created attachment 112354 [details]
bibisect log

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.

Regards,
Peter

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

@Peter
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?

@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.

Created attachment 112472 [details]
Commit 7aa4291 responsible for bug in Save as dialog

Created attachment 112473 [details]
Commit aa539f6 responsible for bug in Open dialog

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.

Regards,
Peter

I picked apart the commits and found the problems are caused by calling CFURLCreateBookmarkDataFromFile:

Offensive line from 7aa4291 (Open dialog bug)
fpicker/source/aqua/NSURL_OOoAdditions.mm

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

Offensive line from aa539f6 (Save dialog bug)
sal/osl/unx/system.c

  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:
http://download.documentfoundation.org/libreoffice/testing/4.3.6/mac/x86/LibreOffice_4.3.6.1_MacOS_x86.dmg

Suggestions?

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 4.1.6.2 on MacOS 10.6.8 does not have this bug.
Thanks a lot!!!

>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.)

@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/

Peter Nowee committed a patch related to this issue.
It has been pushed to "libreoffice-4-3-6":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=9a9a33efaf613f8c4b0e0b4f36053c0fda68187b&h=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:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

Peter Nowee committed a patch related to this issue.
It has been pushed to "libreoffice-4-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=567a0e3bdd3f207bb6f7ae40944516db1048d82e&h=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:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

@Peter
congrats for keep tryng and ultimately fixing this old MAB.
welcome on board to the LibO development team  :-)

@tommy27 Thanks :) and thanks to you and all the others commenting on this bug for your help.

Confirming the fix works for me in 4.3.6 RC2 in my original environment (Mac OS X 10.6.8). Thanks for this!