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? For the time being we changed the code so that posix rename is the default but shouldn't this be addressed? All the best, MAO -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1448 bytes Desc: not available URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20121010/13185f77/attachment.bin>
Hi, On Wed, Oct 10, 2012 at 10:10:43AM +0200, Miguel Oliveira wrote:> 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?I think that a link() implementation that creates a symlink is fundamentally broken and needs to die. Programs can reasonably expect that a link() call that returns success has created hard links, and it is *safe* to then call unlink(old path) - which is standard practice to atomically test-and-set lock files, for example. If you return a symlink instead, you have now made an unsuspecting program destroy its lock file, and created a dangling symlink instead. If link() cannot create a hardlink, it must return an error code (EOPNOTSUPP is what the FreeBSD manpage documents for this case). (Of course this is outside the scope for the question you asked, but I know that a filesystem with the semantics you have described will cause problems for *lots* of programs) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de
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