Sent from my iPhone
> On 28 Mar 2017, at 11:41, Quincey Morris > <quinceymor...@rivergatesoftware.com> wrote: > >> On Mar 26, 2017, at 22:04 , Gerriet M. Denkmann <gerri...@icloud.com> wrote: >> >> [ arrayOfStrings writeToFile: “directoryPath/SortedKeys.plist” atomically: >> YES ]; ← pseudo code > > A couple of points about this line of code, assuming that the method > -[NSArray writeToFile:atomically:] is actually being used: > > 1. This method has a YES/NO result, which you really shouldn’t ignore, if you > do. > I use the result to print an error message. But you are right: I should abandon the whole operation in case of error. > 2. This method is a file API with no outError parameter. All such methods > should be regarded as ancient, undesirable to use, and superseded by a newer > method that does have an outError parameter. The fact that there is no newer > method with an outError parameter tells you that Apple has (essentially) > abandoned this method, and that the replacement API requires a different > approach. My guess is that the intended replacement is to convert the NSArray > to a NSData object yourself (through serialization, archiving, or some > similar technique), and then using one of the more modern NSData file writing > methods to get it onto disk. As the array in question contains strings, none of which should contain a \n I was thinking of converting it into a string, which would then written as UTF16 (which would have the further advantage of reducing the size to about 40%). > > 3. Really, don’t use path-based methods any more. Use the URL-based variant. > (In this case, there is one, but it’s also lacking an outError parameter, so > it also should be abandoned.) > > However, none of the above can explain your crash. The symptoms of the crash > indicate that the directory listed a file called “SortedKeys.plist”, but the > file didn’t actually exist (or couldn’t be read), which is on the face of it > pretty weird. That leads me to: > > 4. You might use “atomically: NO” instead of “atomically: YES”. It’s not > clear whether you expect “SortedKeys.plist” to exist already in the > directory, but I’m guessing not, or that you could delete it manually first. > If the file doesn’t exist, and if you change your code to capture and handle > file-write errors properly, then writing atomically doesn’t have any value, > and it may in rare cases turn out to be actively harmful. There probably will exist an old, not up to date version already. > > A successful non-atomic write is an open/write/close sequence. An atomic > write does that to a temp location on the same HFS volume, then does a file > system atomic “swap” operation to exchange the data of the real and temp > files. On a non-local (e.g. network) or non-HFS volume, the file manager may > not have access to an atomic file swap, so might have to simulate with > renames, moves and/or copies. > > So, an atomic file write involves a longer, possibly quite a lot longer, > sequence of file system operations, and it’s not totally outside the bounds > of possibility that there might be some reordering between this sequence and > other sequences, perhaps even the subsequent directory scan that you do. It > doesn’t seem outside the bounds of possibility that the directory scan might > see the directory in a transitional state. > > This is highly speculative, and other people may have reasons to argue that > such a reordering cannot legally take place, but if you use a non-atomic > write you eliminate any possible timing window on the directory scan, I think. I will abandon the atomic write and just rely on the outcome of the write. If it fails I have no interest in this file at all - the old version is useless anyway. > > That doesn’t really touch the “how to debug?” question, to which I don’t know > the answer, except to suggest you play around trying to make the problem more > reproducible. This is my real problem: so far I have seen this error twice - within 250 days. Using the app several times per day. If I could reproduce the error I am confident of fixing it. I was suspecting a relation with sleep - the first time it occurred at 3:00 (computer should be sleeping) the second time at 17:00 (unlikely to be sleeping, but I'm not sure) Thanks for your suggestions! Kind regards Gerriet _______________________________________________ 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
