• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Generic creation of a symblic link
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

  • Follow-Ups:
    • Re: Generic creation of a symblic link
      • From: Shantonu Sen <email@hidden>
References: 
 >Re: Generic creation of a symblic link (From: Shantonu Sen <email@hidden>)

  • Prev by Date: Re: Generic creation of a symblic link
  • Next by Date: Re: fcntl(fd,F_SETSIZE,?)
  • Previous by thread: Re: Generic creation of a symblic link
  • Next by thread: Re: Generic creation of a symblic link
  • Index(es):
    • Date
    • Thread