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 laur...@nemesys-soft.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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
