On Mar 23, 2011, at 19:49, Ken Thomases wrote: > On Mar 23, 2011, at 7:37 PM, Laurent Daudelin wrote: > >> 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. > > First of all, deprecated doesn't mean "not available". Second, the disk > image I have (maybe from some time ago) has a pre-built binary. > > >> 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? > > Depends on what you mean by "basic". I don't recall you saying which > attributes you were trying to set when you got errors. > > Regards, > Ken >
The first problem I'm having is that "copyItemAtPath:toPath:error:" behaves erratically when using it to copy the content of a folder to another folder that resides on a remote volume accessed through AFP, with full permissions for the folder where I copy the items. In the folder I copy, *all* the subfolders get their modification dates set correctly by "copyItemAtPath:toPath:error:". Now, *most* of the files that are directly in the folder I copy have their creation dates missing and the modification dates set to the time of the copy, e.g. NSFileManager doesn't seem to be able to set those dates properly and will not call "fileManager:shouldProceedAfterError:copyingItemAtPath:toPath:" nor will it return an NSError to explain the problem, when that happens. Right there, that's not good. Then, I did observe that all subfolders have their modification dates set correctly but most of the files in those subfolders don't, they have their modification dates set to the time of the copy, but not all of them. Some of the files in the subfolders have their modification date set correctly. Now, using "setAttributes:ofItemAtPath:error:", some of those files with the incorrect modification dates will be fixed, some won't. When NSFileManager fails to properly set the modification date, it will properly return the error in the NSError object but, like I mentioned before, the message says "You don’t have permission to save the file “XYZ” in the folder “Folder ABC”. "Folder ABC" is the folder I copy, not at all the folder that contains file "XYZ" and the error code is 513, which is "NSFileWriteNoPermissionError = 513, // Write error (permission problem)" according to "FoundationErrors.h". That is not the right error because NSFileManager was able to obviously copy that file after it successfully copied the subfolder inside "Folder ABC". Obviously, there was no permission problem to copy the subfolder and the files in it. That's what is puzzling me. The only real attribute I'm interested in is the modification date. When using "setAttributes:ofItemAtPath:error:", the only object I provide in the attributes NSDictionary is the modification of the original file. Now, I had an older implementation, which I'm trying to replace by a more efficient way to duplicate folders. This older implementation works well using "copyPath:toPath:handler:". This implementation coupled with a call to FSSetCatalogInfo() can successfully duplicate a given folder and all its content with the proper modification dates. I tried in my new implementation to replace my calls to "setAttributes:toItemAtPath:error:" with the FSSetCatalogInfo() but although it fixes a lot of files with incorrect modification dates, there are still a few that aren't fixed. Since the only major difference is the call I make to copy the items in the first place, I'm thinking that "copyPath:toPath:handler:" copies the files more reliably than "copyItemAtPath:toPath:error:" but I haven't been able yet to replace my call to "copyItemAtPath:toPath:error:" because the method sent by NSFileManager to the "handler" only provide the source path. I could work around this but that would require major modifications to my current implementation. Further, I went from "copyPath:toPath:handler:" to "copyItemAtPath:toPath:error:" because the newer method returns an error and because the older one has been deprecated as 10.5. There are no problems when I duplicate a folder to another local disk. That only happens with a remote volume mounted through AFP. I also examined the copied files that didn't have their modification dates set correctly with 'ls'. I did compare them with the original files and I don't see anything different, the owner, group and permissions are exactly the same. I've been working for 3 days on this problem and I'm getting to the end of my rope here. I'm thinking about filing a bug and maybe use my last technical support incident to try to debug this with someone at Apple. Anybody else using "copyItemAtPath:toPath:error:" to copy files to a remote volume here? What should I do? Any suggestion? -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
