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

Reply via email to