[OpenAFS] hardlinks, sftp, and returning EXDEV
Marcus Watts
mdw@spam.ifs.umich.edu
Tue, 11 Dec 2007 19:27:44 -0500
> Date: Tue, 11 Dec 2007 18:37:50 EST
> To: openafs-info@openafs.org
> From: Mike Garrison <mcgarr@umich.edu>
> Subject: [OpenAFS] hardlinks, sftp, and returning EXDEV
>
> So I have a question regarding hardlinks.
>
> I know that hardlinks work properly if they are in the same directory.
> I know it fails if it's to a different directory hierarchy. When you
> attempt to do a hard link across directory boundaries, it returns:
> EXDEV (Invalid cross-device link)
>
> This breaks OpenSSH's sftp if you are attempting to move files. A
> rename of './blah/testfile' to './testing' will result in a failure.
> Essentially, you can't move files around. You can only rename them in
> the same directory via sftp.
>
> I can see returning EXDEV for links across a VOLUME, since then you're
> going across devices, but why does OpenAFS return EXDEV for stuff on
> the same volume? Is there a reason that EXDEV instead of, say
> EOPNOTSUPP?
>
> Thanks,
> Mike Garrison
In AFS, acl information is stored in the directory,
not with the file. If you could hardlink files to other
directories, the acl logic would become much less useful.
[ acl information is stored per-directory because
only directories have room to store small "arbitrary" sized
chunks of data. Files or inodes do not in general
have such a slot, although increasingly modern
filesystems may have room for extended attributes
or multiple data forks. ]
EXDEV is a very old error code, which any application that
moves files between directories ought to expect. Commands such
as "mv" may restort to "cp/rm" in this case.
EOPNOTSUPP dates from the introducion of networking, and
as you might then expect, is used to report certain kinds
of network errors. It would not be reasonable for an
application to decide to do "cp/rm" in the event of
getting this error.
-Marcus Watts