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