bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE : Re: [PATCH] file-has-acl: revert unintended change in behavior of l


From: Bastien ROUCARIES
Subject: RE : Re: [PATCH] file-has-acl: revert unintended change in behavior of ls -L
Date: Mon, 3 Oct 2011 20:46:59 +0200

Yes it is possible to mount file and it is call a bind mount. See man page of mount, and it is used in pratice essentially for /dev/null but it could be used for any regular file

Le 3 oct. 2011 19:29, "Kamil Dudka" <address@hidden> a écrit :

On Monday 03 October 2011 18:25:10 Bruno Haible wrote:
> Kamil Dudka wrote:
> > > 2) see a test ca...

Fair enough.  I am adding this to my TODO list, although there are more urgent
issues preventing me from working on this atm.


> Thanks for that background. So we're looking at "ls -l /media" or
> "ls -ld mountpoint". Since yo...

Well, symlinks to mount points were not mentioned in that bug.  I would need
to ask kernel guys whether symlinks to mount points are worth to consider in
this fix at all.


> So in fact we have 9 cases:
> a) A non-symlink, non-directory. Here acl_extended_file_nofollow ...

If I understand this, you expect non-directories cannot be mount points, thus
the call cannot trigger the mount, right?


> b) A directory that is not a mount point.
> c) A mount point.
> d) A symlink to a file, wit...

The behavior of ls wrt. tregerring mounts is implementation defined, isn't it?
Let's take it such and just choose the implementaion that makes sense.


> So how do these 9 cases need to be handled:
> a) Either acl_extended_file_nofollow or acl_exten...

The Problem is that case a) is not detectable on its own.


> I'm trying to avoid useless system calls. If
> ! S_ISLNK (sb->st_mode) && ! S_ISDIR (sb->st_mo...

Is optimization the only purpose of this change?  I would then prefer to get
it working first and optimize it later on.


> But still still does not fix the problem of case f). Here, with your
> current patch, "ls -lLd sy...

Case f) has never worked, nobody complained.  Partial fix is better than no
fix.  The last patch does not break anything that worked before, does it?


> IMO, there are two solutions to this:
> - Either convince the kernel people to introduce a diff...

This is non-starter.  Kernel developers are not interested in optimizing out
stat() calls from user-space.  There is a similar, more serious, bug open for
years.  Nobody cares.

https://bugzilla.redhat.com/501848


> - Or use code equivalent to canonicalize_filename_mode(CAN_EXISTING).

I am personally not intersted in changing something that works unless there is
a user that needs the change actually.

Kamil


reply via email to

[Prev in Thread] Current Thread [Next in Thread]