|
Message-ID: <20150827013904.GS32742@brightrain.aerifal.cx> Date: Wed, 26 Aug 2015 21:39:04 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: lchmod on Linux On Thu, Aug 27, 2015 at 12:02:41AM +0200, Laurent Bercot wrote: > On 26/08/2015 23:09, Tomasz Sterna wrote: > >One thing could be always returning 0, as this is really a no-op on > >Linux. > > I tend to agree with that. > https://www.freebsd.org/cgi/man.cgi?query=lchmod&sektion=2 does not > describe EOPNOTSUPP as a possible error code. Is there a reason not > to make lchmod return 0 when the underlying fchmodat returns > -1 EOPNOTSUPP? Conceptually I think it's wrong to return 0 when the operation wasn't performed. There's also an argument to be made that lchmod should be equivalent to the corresponding fchmodat call; if it were ever standardized, it almost certainly would be. If there were a strong compatibility benefit to be had by making it return 0 despite these things, that would certainly be worth weighing in on, but I don't think there is any such issue. There are very few users of lchown, and IIRC the other ones we've found handle it fine already. > >>EOPNOTSUP is a documented result for fchmodat, [...] > >Is it a documented result for lchmod? (Google is no help here.) > > Not according to the FreeBSD doc. > The thing is, lchmod() is not POSIX, it's only BSD (I could find > doc for FreeBSD and MacOS X); the best behaviour is not to use it > at all. What libarchive should really do is to replace lchmod() with > fchmodat() and explicitly test for EOPNOTSUPP. I agree entirely with this. lchown should not be used at all if fchmodat is supported, since the latter has standardized behavior you can rely upon. Can we just propose a patch to libarchive to use fchmodat when it exists and properly check for EOPNOTSUPP? Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.