safe_rename() and verifying the result of link(2)
Kevin J. McCarthy
kevin at 8t8.us
Tue Aug 21 14:07:15 UTC 2018
On Tue, Aug 21, 2018 at 11:30:03AM +0200, Vincent Lefevre wrote:
> 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.
That was my reading too. :-)
> Perhaps, but the sshfs(1) man page says:
> [...]
> If hard links don't work perfectly (can there be more serious errors
> than the inode number?), it may be better to disable them.
I agree. My goal here isn't to "support" sshfs as much as it is to
prevent a disastrous link-creating infinite loop in Mutt; and to do so
without making Mutt less safe.
I don't like removing 20-year old safety checks, but I think it's okay
to do so for the case where link() returns 0. I've been slow to act in
order to give others a chance to chime in, and I greatly appreciate you
doing so.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.mutt.org/pipermail/mutt-dev/attachments/20180821/c668b79e/attachment.asc>
More information about the Mutt-dev
mailing list