On 24.06.2014, at 14:05, Felix Franz <fr...@ergosign.de> wrote: > Hello, > > we got bug reports, that on some machines Save As writes a corrupt file. > Now we have access to a machine where this happens, and even a basic > test-project (Document-template using CoreData in Xcode) exhibits the > same problem. > > The machine is running OSX 10.9.3. On this machine it is easy to reproduce. > The first Save of a new file works without problems, normal save-operations > are working flawlessly. Choosing Save as results in a file without any data. > > Overwriting writeToURL:ofType:forSaveOperation:originalContentsURL:error: > shows a > difference between a machine where it works and the faulty one. > > On the working machine the absoluteURL is a temporary-URL > (file://localhost/private/var/folders/2t/th51wqw13ms24fvjdzv0xbb00000gp/T/TemporaryItems/(A%20Document%20Being%20Saved%20By%20savetest)/Untitled.binary), > whereas on the machine where save does not work > shows the URL chosen in the Save panel.
I found the cause for this behavior. On the machine where the error happens, the folders where the file is saved had the following ACL: 0: user:_spotlight inherited allow list,search,readattr,readextattr,readsecurity,file_inherit,directory_inherit After stepping through the code in AppKit it looks like it gets the ACL from the folder and if some flags are set (ACL_ENTRY_ONLY_INHERIT|ACL_ENTRY_LIMIT_INHERIT|ACL_ENTRY_DIRECTORY_INHERIT|ACL_ENTRY_FILE_INHERIT) it decides to not use the normal save in a temporary-folder method. (not quiet sure about it, but this let me to look at the ACLs of the folder). This in case triggers a weird behavior in NSPersistentDocument. As mentioned in the original post if writeToURL:ofType:forSaveOperation:originalContentsURL:error: is called as NSSaveAsOperation with a nil-parameter for the original content url it saves to the existing file and writes an empty file to the url. Removing the inherited ACL fixed it. Not quiet sure which workaround to choose. Either looking/changing the ACLs, or supply self.fileURL in writeToURL:… if originalContentsURL is nil. Disk Utility "Repair Permissions” did not complain about the ACLs. Cheers, Felix > > The writeToURL:…-methods returns YES. > > After a Save As in a document already saved before the originalContentsURL is > nil > on the faulty machine, on the working one it points to the original file. > > I guess something is wrong with the account. In a fresh user-account > everything works > as expected on the machine. But unfortunately we can’t say the customer: “if > this happens > just create a new account” :) > > I checked the Permissions on the machine. The user has full-access to the > folder returned > by NSTemporaryDirectory(). > > I tried it with binary and sqlite-store (we are using sqlite in our app). > > Does anyone has some ideas what to try? The logs don’t show anything. > > Thanks in advance, and sorry for the long post. > > Cheers, > > Felix > > > > > > > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/franz%40ergosign.de > > This email sent to fr...@ergosign.de _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
