[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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.
