recent sshfs link bug

Thomas Bushnell BSG tb at
Fri Aug 29 02:44:09 EDT 2008

This is in re the recent fix by Micha Lenk for the bug where gnucash
dealt badly with lock files in the case link returns ENOSYS.

I understand from the irc log that Derek thinks it is foolish to try the
copying method for most errors.  I want to disagree strongly.

First, it is a rare case, and trying copying is a harmless thing to do.

But more than that, this bug pointed out the problem: some link calls
might return EOPNOTSUPP, and ENOSYS now, and the actual documented error
that is supposed to be returned in this sort of case is actually EPERM.

And there is of course ENLINK and EMLINK, both of which are errors that
cause link to fail, but a copy might succeed.

A filesystem might choose to implement an access control which requires
bits to link to a file distinct from simply making a new one, in which
case link might fail with EACCES, but not creating.

I strongly urge that for any error, fall back to the copying method.

Failing that, change the sense of the test.  Right now, the fall back
happens only for recognized errors.  Change that.  Omit the fall back
only in the case of a listed error.  That is, instead if "if err =
EOPNOTSUPP", change it to "if err != EROFS" or whatever other error you
are *certain*--absolutely certain--cannot occur without file creation

But I submit there are *no* such errors.  For example, EROFS and EIO are
potentially transient conditions!


More information about the gnucash-devel mailing list