Page 1 of 1

lchown() calls on symbolic links

PostPosted: Fri Oct 17, 2014 11:28 am
by roemer
I experience an issue with my file synchronisation tool-of-choice, ChronoSync, that cannot set the userID and groupID correctly on symbolic links on ZFS volumes. It works fine when syncing between HFS+ volumes, but fails from HFS+ to ZFS. After some discussion with ChronoSync's technical support, they mentioned that they are using a standard OSX API for modifying user and groups of symbolic links: lchown()
Note that I can manually modify any user/group ids on symbolic links with command line tools on ZFS.
I don't know however which system call those command line tools rely on. Does anyone else have a similar problem or know whether lchown() usage might have some limitations on ZFS? Looking at Apple's documentation of that call, I do not see many possibilities for sudden problems...

Re: lchown() calls on symbolic links

PostPosted: Fri Oct 17, 2014 10:02 pm
by lundman
As you say, it does work from commandline
Code: Select all
-rw-r--r--+  1 lundman  wheel     0 Oct 18 14:53 helloworld4.jpg
lrwxr-xr-x+  1 root  wheel      15 Oct 18 14:53 symlink -> helloworld4.jpg

# chown -h openzfs:sys symlink

-rw-r--r--+  1 lundman  wheel     0 Oct 18 14:53 helloworld4.jpg
lrwxr-xr-x+  1 openzfs  sys      15 Oct 18 14:53 symlink -> helloworld4.jpg

# dtruss -f chown -h openzfs:sys symlink

  285/0x976:  lchown("symlink\0", 0x1F6, 0x3)            = 0 0



As you can see, chown -h, uses the lchown system call and appears to have no issues with it. It is possible something goes wrong with a call near to when they call lchown.
Even though you can use dtruss, or turn on ZFS's vnop_debug, both are very verbose. You'll want to pare it down to a small test, like, single symlink.