process_rename assumes hard links?

[Damien Miller]

On Wed, 10 Oct 2012, Miguel Oliveira wrote:

> Hi,
>
> My name is Miguel Oliveira and I work at the University of Oslo
> where we just deployed a new high performance compute cluster. Our
> current parallel filesystem is FhGFS and we started having complaints
> about problems with file transfers? We managed to diagnose this to
> particular ssh clients that do not support the new posix rename
> extension.
>
> Bottom line our filesystem does not support hard links and I think the
> problem is that process_rename assumes link(old path,newpath) will
> always return one. Shouldn't this situation, i.e., link returning a
> symlink, be contemplated in the code?

link() shouldn't return a symlink(), it is a fundamentally different
operation. It should return a hard link or errno=EOPNOTSUPP.

> For the time being we changed the code so that posix rename is the
> default but shouldn't this be addressed?

process_rename() already does the right thing when the underlying
operating system tell the truth and returns errno=EOPNOTSUPP when
it doesn't support link().

It can hardly be blamed for getting it wrong when the OS or FS lies...

All that being said, I don't think you'll suffer much for your local
change. I've never seen anything that actually depends on the silly
sftp rename semantics over the POSIX ones.

-d