Re: Generic creation of a symblic link
Re: Generic creation of a symblic link
- Subject: Re: Generic creation of a symblic link
- From: Shantonu Sen <email@hidden>
- Date: Fri, 12 Oct 2012 00:19:31 -0700
Have you run dtruss on a test program using the File Manager APIs? There's no guarantee that those deprecated APIs are implemented in terms of supported BSD-level APIs, but you'd at least get some guidance on that.
The O_SYMLINK flag exists so that you can get a file descriptor to an object in the filesystem namespace without dereferencing symlinks. This can be used to call fstat(2) on the symlink, equivalent to lstat(2) on the original path. It's not a general-purpose mechanism to break through the filesystem abstractions. The same applies to opening directories, which you can also do, but the resulting file descriptor is designed to be used with getdirentries(2) but not read(2) (please don't do this either, use readdir(3).
Shantonu
On Oct 12, 2012, at 12:04 AM, James Bucanek <email@hidden> wrote:
> Shantonu Sen <mailto:email@hidden> wrote (Thursday, October 11, 2012 5:55 PM -0700):
>
>> So, Um. What are you trying to do. There is no semantic in OS X for rewriting
>> symlink targets without recreating the symlink.
>
> I'm discovering that. :P
>
> I'm author of a backup utility. This was originally written using the Carbon APIs. In that API, I could open and read any file, including symlinks. To restore a symlink, I would create a file of the correct type, open it, rewrite the original contents, and lo and behold a restored symlink would appear in the filesystem--just like any other file.
>
> With the Carbon APIs deprecated, I'm rewriting all of my file handling to use the BSD APIs. Clearly, there's a serious impedance mismatch between the two, and it's now obvious that the Carbon framework was doing a lot of slight of hand behind the scenes. What I'm doing now is trying to figure out what that was so I can perform the same actions with the BSD APIs.
>
> The point where I've gone off the rails today is assuming that there was an analog to reading and writing a symlink directly (as if it was a regular file), because the Carbon APIs would allow one to do that. This was reinforced by the open() command's documentation that states the O_SYMLINK flag would allow direct access to the symlink file itself:
>
> If O_SYMLINK is used in the mask and the target file passed to open() is a symbolic
> link then the open() will be for the symbolic link itself, not what it links to.
>
> But after writing some test programs this afternoon, I find that's not true at all. Sure, you can open the symlink file, but then you can't do anything with it. read() and write() return EPERM errors.
>
> So clearly I'm going to have to treat symbolic links completely differently than regular files. That's no big deal for my code, it's just been a meandering road to get there.
>
> As of now, it would appear that the only way to read the contents of a symbolic link is using the readlink() function, and the only way to write one is to use symlink().
>
> --
> James Bucanek
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden