https://bugs.freedesktop.org/show_bug.cgi?id=60338
--- Comment #5 from jwoithe <[email protected]> --- A user of mine reported a very similar problem to this earlier today. This was the libreoffice.org 32-bit binary release of 4.2.1 running under 32-bit Linux (Slackware 13.37). They took an existing ODT file created libreoffice 4.0.2 (let's call it A.odt) and did File|SaveAs to create a fresh copy under a different name (B.odt). The newly created ODT file (B.odt) had permissions 600, as oppposed to 644 that has been seen when the exact same process was done in the past. Furthermore, when the newly created file (B.odt) was File|ExportToPDF, the resulting PDF file had 600 permissions. Changing the ODT to have 644 using chmod, loading the result and exporting to PDF still had the PDF with 644 permissions. Loading A.odt and exporting to PDF had 600 permissions on the PDF. Creating a new file and saving that gave the new file 644 permissions, as expected. Loading this file and doing "SaveAs" resulted in 644 permissions on the new ODT file. Exporting either file resulted in permissions of 644 on the PDF files. After doing this, loading B.odt and repeating the export to PDF resulted in 600 permissions on the PDF. I then loaded another ODT file (C.odt) which had been created with an earlier version of libreoffice. Exporting this to PDF resulted in 600 permissions. At this stage it seemed the bogus permissions when B.odt was exported to PDF were 100% reproducible. Unfortunately it is not possible to post that file due to the nature of the information it contains. I then attempted to delete things from it, testing the permissions of the exported PDF at various times. I got nearly to the top of the file when the PDF suddenly started acquiring 644 permissions. I reloaded C.odt, did an export, and got 600 permissions. I returned to B.odt, inserted a space, resaved, exported and had 600 permissions. I removed single block of text, exported, and got 644 permissions. I went back to B.pdf and exported without making any changes, and got 644. From this point on, no matter what I did I was not able to get anything except the expected 644 permissions. While it initially appeared that the documents we had exhibited the problem on demand, the issue mysteriously went away without anything being done beyond the repeated libreoffice tests as described. The exact same procedure which triggered the problem earlier every time it was done now completely fails to do the wrong thing. Nothing changed on the computer concerned and there were no logout/login sequences in between. I have noticed that unlike 4.1.x and earlier, with version 4.2.1 I do now see "XDM authorization key matches an existing client!" each time I start libreoffice, but I very much doubt this has anything to do with the permission problems described, especially since this message still appears when the permission malfunction does not. Note that we ourselves have not observed this problem under any earlier version of libreoffice. Based on the above descriptions, it seems that libreoffice 4.2.1 can be added to the versions which suffer from the problem. Furthermore, it appears that dvcroft's suggestion of an uninitialised variable (or something similar) is quite likely given the intermittant nature of the misbehaviour. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
