Re: Problem with setAttributesOfItemAtPath:error:
Re: Problem with setAttributesOfItemAtPath:error:
- Subject: Re: Problem with setAttributesOfItemAtPath:error:
- From: Laurent Daudelin <email@hidden>
- Date: Wed, 23 Mar 2011 17:37:46 -0700
On Mar 23, 2011, at 16:38, Ken Thomases wrote:
> On Mar 23, 2011, at 6:17 PM, Laurent Daudelin wrote:
>
>> I've been using NSFileManager "copyItemAtPath:toPath:error:" and it generally works well. However, when trying to copy files from a local folder to a folder on a remote volume, "copyItemAtPath:toPath:error:" will sometimes fails to set the creation and modification dates of the item copied. The problem is that when it fails to set the attributes of the item it copies, it will not report it as an error (not sure if this is a bug, this is kind of very annoying).
>>
>> In any case, I wanted to dig a little deeper to find what's going on with that since I set permissions on the original folder to read/write for everyone and the receiving or destination folder on the remote drive with the same read/write permission to everybody. Of course, I connected with my user ID and password on the remote volume. When I check the permissions in the Finder, I see that both the source and destination folders have read/write permissions for the owner, the group and everybody. So, from there, I decided to systematically set the attributes myself, since "copyItemAtPath:toPath:error:" is failing to do it. So, I'm using "attributesOfItemAtPath:error:" and "setAttributesOfItemAtPath:error" to try to set the attributes of the copied item to that of the original item. I was not expecting it to really succeed but at least I was hoping to catch the error. That's where it gets interesting. When it fails, the localized description of the error is invariably "You don’t have permission to save the file “Blah” in the folder “Folder Blah”. "Folder Blah" in this case is the destination folder on the remote drive.
>>
>> So, what am I missing here? The error is plain wrong in the first place because I was not attempting to copy the item, it's already copied! I just checked again "Folder Blah" permissions and they are still set to read/write to owner, group and everybody.
>>
>> Can someone explains this result?
>
> Not all file system drivers support all attributes. Even if, on the file server, the local file system driver supports the attributes you're trying to set, the file sharing protocol may not. Even if the file sharing protocol does, the file system driver on the client machine that implements that protocol may not.
>
> You can see what happens when you drop down to using lower-level routines like setattrlist(). You can also use Apple's FSMegaInfo sample code to query the file system's capabilities using getattrlist(). (You can, of course, write your own tool to query that, but FSMegaInfo is ready-built.)
>
> Regards,
> Ken
>
Hello Ken.
I actually looked at FSMegaInfo but when I built it, I realized that it was using a lot of deprecated functions in 10.6 so I decided against using any part of it because of the amount of work that would be required to rewrite some parts of it.
And yes, I do understand that different file systems will have different attributes. But, I'm sharing that remote volume from an Intel iMac running 10.5.8, connected to it through AFP. Shouldn't AFP supports basic file attributes? Not using Samba here or WebDAV, just plain Finder "Shared" computers...
-Laurent.
--
Laurent Daudelin
AIM/iChat/Skype:LaurentDaudelin http://www.nemesys-soft.com/
Logiciels Nemesys Software email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden