Re: Generic creation of a symblic link
Re: Generic creation of a symblic link
- Subject: Re: Generic creation of a symblic link
- From: Ken Hornstein <email@hidden>
- Date: Thu, 11 Oct 2012 23:29:31 -0400
>I want to use the BSD API to create an empty symbolic link file
>and then write its contents. There's no obvious way of doing
>this with open(), as the object type flags in the mode parameter
>appear to be ignored.
I'm going to echo others in wondering _what_ you're really trying to do,
but let me explain things a bit.
symlinks are a bit magical; in terms of the BSD API, they mostly don't really
exist as distinct files; they always refer to the file they're pointing to.
If the target file doesn't exist, you get ENOENT when you try to do stuff
with the symlink. The big exception is of course lstat(); that's the main
way to find out stuff about a symlink (there are a few other minor
exceptions). Now of course symlinks are IMPLEMENTED as distinct files,
but that's mostly hidden from you via the API. You can't expect to be
able to rewrite their contents like you can with a regular file; the only
way to change the target of a symlink is to unlink() it and create it anew
(I'm talking about the traditional POSIX API; some OSes may have extensions
that I'm not aware of).
>I tried to research this by finding out how the symbolic link
>creation function symlink() is implemented ... but I can't seem
>to find its source code. I've grep'd the entire Libc-825.25
>folder from the latest Darwin release. I can see where other
>functions call it, but not where it's implemented.
It's because it's a system call; it goes right into the operating
system (the big clue here is that it's man page is in section 2).
If you want to dig into that ... well, like Paul Nelson already
said, the xnu sources are going to be your new best friend. The
basic implementation of the symlink() system call is in
$(XNU)/bsd/vfs/vfs_syscalls.c, but once you look at that you'll
find it calls a mysterious function called VNOP_SYMLINK() which
does the real work. The _real_ function in that case depends on
the backend filesystem, but Paul already gave you the function you
can look at for HFS. And don't ask me to explain how you get from
VNOP_SYMLINK() to hfs_vnop_symlink, because that would take days :-)
To answer your OTHER question:
>What's the third parameter of fcntl() supposed to be when the
>cmd is F_SETSIZE?
It takes an off_t. Again, fcntl() is a system call, so you need to look
at the xnu sources. Specifically ... $(XNU)/bsd/kern/kern_descrip.c.
--Ken
_______________________________________________
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