NSFileCoordinator operations on a directory (and it's content)

2023-07-20 Thread Dragan Milić via Cocoa-dev
Since my question is about specific Cocoa API, but it also involves file system 
operations, I don't know it the appropriate place to ask is here or 
Filesystem-dev list, so I'll ask on both (and hope nobody will mind it :-))

I have an application, which "messes" with files in different ways. It can 
modify, move, copy, even delete them. So far all file operations were performed 
directly, without any checking if affected files were already busy or locked by 
other processes (or even the same application). So, in case a locked file is 
encountered and the operation failed, an appropriate error was reported.

Now I want to enhance this behaviour and ensure two things:

- make sure all files to be performed on are available for the operation in 
question (not busy/locked by other processes)

- before the operation starts, inform other processes, so they can act 
accordingly if necessary.

The most obvious solution to me is using NSFileCoordinator class and its 
reading/writing options. And even though documentation for this class is quite 
descriptive and helpful, I have some unanswered questions. So before doing my 
own tests (and perhaps even coming to potentially wrong conclusions), I'd like 
to ask here if someone has already had experience with this class and what I 
want to achieve with it.

The basic question is: if I start coordinated operation (reading or writing) on 
a directory identified by an URL, does that operation intent automatically 
spans to all files and folders in the directory, all the way down the whole 
directory hierarchy?

Or let me try to me more specific; I want to read all files in a certain 
directory, but then also list all its subfolders and read their (sub)files and 
go on like that down the directory hierarchy. While doing so, I don't want any 
other process to mess (modify, delete…) with any of those subfiles and 
subdirectories in the hierarchy. Is it enough to request coordinated reading to 
the root directory only, or do I still need to require coordinating reading to 
subfiles and subfolders? Or to put it another way, if I start coordinated 
reading on the root directory only, will other processes still be allowed to 
mess with subfiles and subdirectories?

Or does this behaviour depend on the read/write option I actually want to 
perform? For example, requesting NSFileCoordinatorReadingWithoutChanges on a 
directory doesn't necessarily imply reading intent to all its subfolders and 
subfiles down the hierarchy. But requesting e.g. 
NSFileCoordinatorWritingForDeleting on a directory certainly implies the 
deletion will also affect all its subfiles and subfolders.

I hope I was clear enough about what I want to achieve. Thanks for any insights.

-- Dragan
___

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


Re: How do decipher an exception in the log file

2023-07-20 Thread Saagar Jha via Cocoa-dev
Console should have it. That crash log will have the base address in it that 
you can use to symbolicate things.

Saagar Jha

> On Jul 18, 2023, at 16:01, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> 
>> That number is 0x7FFF, which is particularly recognizable and 
>> happens to be the value of NSNotFound.
>> 
>> I imagine that in the preceding line of code you called -indexOfObject: on 
>> an array that didn't contain the object, but then failed to test the value 
>> against NSNotFound before trying to fetch from that index.
>> 
> 
> Thanks a million!
> Very interesting observation. 
> The fact that  
>  9223372036854775807 = 0x7FFF 
> escaped me.
> And, indeed, I do have a few indexOfObject's in my code, and luckily not that 
> many.
> 
> 
>>> More precisely, is there a way I can determine the location in the code 
>>> where the exception occurred?
>> 
>> Do you have symbols for the particular build of the app that crashed? If so, 
>> there ought to be some way to symbolicate the list of addresses in the 
>> "Stack trace:" line of the log messages... although maybe not, without 
>> knowing the base load address of the executable.
> 
> Problem is that its a screensaver (i.e., a .saver file).
> I guess the base adress is always different, at least I have no idea what the 
> base address might be.
> 
>> A full-on crash report, rather than log messages, would be a lot more useful.
> 
> Where would i find that crash report, given its a screensaver?
> Just in case something like that happens again ...
> 
> 
> Best regards, Gabriel
> 
> ___
> 
> 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/saagar%40saagarjha.com
> 
> This email sent to saa...@saagarjha.com

___

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