Re: Generic creation of a symblic link
Re: Generic creation of a symblic link
- Subject: Re: Generic creation of a symblic link
- From: James Bucanek <email@hidden>
- Date: Fri, 12 Oct 2012 00:04:59 -0700
- Authentication-results: symauth.service.identifier
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