pseudo-symlinks on directories

pseudo-symlinks on directories

[Steve French]

There is a file type similar in some ways to symlinks, called junctions
(For NTFS and CIFS they are a form of "reparse point") that is supported
in CIFS and which a few filesystems have to deal with.   The only valid
case I have seen is that in which directories (rather than files) are
marked as reparse points but that leads to the question -

Should junctions (reparse points) be treated as symlinks or as
directories?

Linux's NTFS filesystem seems to ignore the flag and treat them as
directories.  I had been treating them in the cifs filesystem as a
symlink (although temporarily I do not support readlink on them) but the
path that they return typically has what Linux what consider an invalid
server local absolute path (e.g. "c:\target_dir") which follow_link
would not be able to handle.   If I ignore the reparse flag and treat
them as directories (as NTFS does) rather than symlinks, they would look
much like a hardlinked directory (if that were legal) but with different
inode numbers on source and target.  If I treat it as a symlink then I
would need to go through hoops in cifs_readlink and cifs_followlink to
be able to return the proper information in "ls -l" and similar commands
but still allow cd to the directory to work.   

There is a small amount of useful information that an application has
when it knows that a directory is symlinked, even though the path can
not be followed rationally on the client, but I think that it is not
enough to make it worth while to continue to treat as symlinks.

My gut reaction is to follow a recent patch suggestion and change cifs
client to treat these junctions/reparse points as directories (which is
a trivial change to the cifs vfs code), perhaps with a fake xattr for
the inode that gives the reparse info.

Re: pseudo-symlinks on directories

[Erik Latoshek]

maybe we must look at this issue at safety point, when deleting such 
directories (that look like simple dirs but are links and application 
cannot know this) we will delete all files inside even directories to 
which link points.

i think that this will be surprising for user, "deleted one directory 
but lost files in other directories". he cannot know that directory is 
linked.

so i think that even making directory look like not-working link is ok.

Re: [linux-cifs-client] Re: pseudo-symlinks on directories

[Steven French]

> he cannot know that directory is linked.

He could, albeit awkwardly, if I export the dos attributes via a 
pseudo-xattr (they already get stored in the cifs vfs specific part of the 
inode) since the reparse point bit would be set there.  Note that Samba 
has talked about doing this too to save dos attrs (and would be something 
vfat, NTFS and a few others also export). 

As an alternative, the reparse info itself could be queried (the cifs vfs 
has the code necessary to query reparse info, but it is dead code in 2.6.9 
and later) whenever someone asks for xattr  such as "system.reparse_info" 
or some such.


Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com