Fri 21 Jun 2013 08:09:32 PM UTC, original submission:
Running gnustep-base v1.24.4 on x86 Debian Wheezy.
copyItemsAtPath:toPath:error: fails if the source path contains subfolders and those subfolder have user/group permissions that 'exceed' the permissions of the user running the copyItems command.
Simple example:
#import <Cocoa/Cocoa.h>
int main(int argc, char *argv_p[])
{
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
NSError *error = nil;
[[NSFileManager defaultManager] copyItemAtPath:@"/usr/local/lib/GNUstep/Bundles" toPath:[@"~/Bundles" stringByExpandingTildeInPath] error:&error];
if(error)
{
NSLog(@"%@", error);
}
[pool release];
return 0;
}
When first run this code will error:
2013-06-21 16:05:03.099 test[7216] Unable to change NSFileGroupOwnerAccountID to '50' - Operation not permitted
subsequent runs will error:
2013-06-21 16:07:15.769 test[7279] [NSError-initWithDomain:code:userInfo:] with nil domain
It seems that -changeFileAttributes:atPath: is used to try to 'restore' the attributes of the copied sub-folder to that of the original subfolder. In my example the subfolder is owned by root/staff, and my user is not a member of staff.
The subfolder is still readable by me.
Should NSFileManager really error if it can't restore the user and/or group? The files and folders have been copied and assigned to the user already.
|