[Rapzid]

Per the documentation this seems to be the case. However, I'd be curious to know if the implementation of the symlink syscall does or does not fsync the new file while in kernel space...

The fact that it does or does not should actually be in the documentation IMHO; probably a good enhancement request.

[geocar]

Symlinks are directory entries, not files, so you need to sync the directory that contains the link.

POSIX does (for some strange reason) permit a symbolic link to have an "inode" (well, d_ino), but there is no way to open this "inode", and no UNIX implementations to my knowledge do this.

[josefbacik]

Symlinks are implemented as files in Linux, we write the path into the file that you are pointing to, so there most certainly is data that must be fsync()'ed if you want it to be persistent.

Edit: If you want to fsync the symlink you can do an open with nofollow iirc (on my phone so I can't check) so you get the actual symlink and not its target.

[geocar]

Yes, but Linux recognises the need to sync the file object when you fsync() the directory that it is in. There is no way to fsync() the symlink directly.

[Rapzid]

I'm not sure if this is picking nits, but symlinks have their own inode number.. This ought to classify them as a file.

HOWEVER, looking into it it seems that the target may actually be stored in the inode. This mean the symlink, though a file, has no contents and thus requires no fsync. Does this sound about right?

[geocar]

> I'm not sure if this is picking nits, but symlinks have their own inode number..

No they don't.

First of all, POSIX doesn't use the term "inode number" but "file serial number" which is silly wankery since there's no way to access a file using its "file serial number". They might as well say it was "implementation defined".

Secondly, POSIX used to specify[1] that their inode was "unspecified" because UNIX systems don't store symbolic links in separate inodes, but in the directory that contains them. Now, POSIX specifies symbolic links do have a "file serial number"[2], which could be implemented as a separate file block (confusingly Linux calls this an "inode" which has nothing to do with what UNIX called an inode -- a better term might be "virtual inode" but Linux uses that for something else entirely...)

To this end, I think the only sensible interpretation is the original one: UNIX symbolic links don't have inodes, and POSIX symbolic links might as well have a "hash" of the file contents in the "file serial number" since you can't do anything with it anyway.

[1]: http://pubs.opengroup.org/onlinepubs/009695399/functions/rea...

[2]: http://pubs.opengroup.org/onlinepubs/9699919799/functions/re...

> HOWEVER, looking into it it seems that the target may actually be stored in the inode. This mean the symlink, though a file, has no contents and thus requires no fsync. Does this sound about right?

You have to fsync() the directory that contains the symlink.

[Rapzid]

I see what your saying, I believe. I also think we are possibly talking about different things(me linux and you POSIX). AFAICT my symlinks have unique inodes on linux...

[geocar]

Yes.

What UNIX called an inode is unfortunately not what Linux now calls an inode. That thing might have better names, but we are stuck with it.

I don't know if it is useful to say "Linux inode" because that can refer to both what "ext4" calls an inode and what the Linux kernel refers to as a "virtual inode".

What POSIX called a "file serial number" (and goes in the `d_ino` field) is also not what Linux calls an inode. I sometimes think this is okay to refer to as a "POSIX inode" because POSIX doesn't otherwise use the term, and up until SUS6 the POSIX file serial number was compatible with a UNIX inode.

However I'm not trying to nit: Trying to develop a simplified mental model is essential to determining what to do (and what to sync!). From an application point of view, knowing that a symbolic link has a name (and contents) and lives in a directory, can help guide us.

[caf]

What UNIX called an inode is unfortunately not what Linux now calls an inode. That thing might have better names, but we are stuck with it.

How so? Here's a v6 on-disk inode: https://github.com/hephaex/unix-v6/blob/master/ino.h

and here's an ext4 on-disk inode: http://lxr.free-electrons.com/source/fs/ext4/ext4.h#L704

The latter is considerably larger, to be sure, but still contains all of the fields from the former (many of them with the same name!).