Make sure you use the do-not-traverse-symbolic-links form when constructing your FSRef for the FSSetCatalogInfo call. I do remember having to do that call in similar circumstances, which is why I was going to try FSCopyObjectAsync to see if that would solve all those issues as well as get in-progress status, but I held off until that APIs memory leaks were fixed (which became bad when copying a few thousand files), and it was fixed in 10.6.7 (it was present in all of 10.6 up to 10.6.6).
- Gary L. Wade (Sent from my iPad) On Mar 23, 2011, at 11:14 PM, Laurent Daudelin <laur...@nemesys-soft.com> wrote: > 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/garywade%40desisoftsystems.com > > This email sent to garyw...@desisoftsystems.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
