On 2018-08-14 14:30:57 -0700, Kevin J. McCarthy wrote:
> I think if the link() returns 0, it's safe for the code to assume all
> went well.
The Linux link(2) man page says:
BUGS
On NFS filesystems, the return code may be wrong in case the NFS server
performs the link creation and dies before it can say so. Use stat(2)
to find out if the link got created.
But as I understand it, this means that the link got created, but the
system thinks that it wasn't, and link() returns a non-zero value.
So, I also think that if link() returns 0, then all went well.
> So, the fix I plan to make is remove the compare_stat call
> afterwards, but keep the stat calls for now:
>
> lib.c:
> @@ -517,12 +517,21 @@ int safe_rename (const char *src, const char *target)
> * did already exist.
> */
>
> +#if 0
> + /*
> + * Remove this check, because it causes problems with maildir on
> + * filesystems that don't properly support hard links, such as
> + * sshfs. The filesystem creates the link, but the resulting file
> + * is given a different inode number by the sshfs layer. This results in
> an
> + * infinite loop of created files.
> + */
> if (compare_stat (&ssb, &tsb) == -1)
> {
> dprint (1, (debugfile, "safe_rename: stat blocks for %s and %s diverge;
> pretending EEXIST.\n", src, target));
> errno = EEXIST;
> return -1;
> }
> +#endif
>
> /*
> * Unlink the original link. Should we really ignore the return
Perhaps, but the sshfs(1) man page says:
-o disable_hardlink
link(2) will return with errno set to ENOSYS. Hard links
don't currently work perfectly on sshfs, and this confuses
some programs. If that happens try disabling hard links with
this option.
If hard links don't work perfectly (can there be more serious errors
than the inode number?), it may be better to disable them.
--
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
