bug#34438: [8.30, info] doc error in -R
On 11/02/19 09:29, Filipp Gunbin wrote: > Hi, > > There's a small bug in doc here: > > ‘-R’ > ‘--rfc-email’ > ... > This format conforms to Internet RFCs 5322 > (https://tools.ietf.org/search/rfc5322), 822 > ^ > (https://tools.ietf.org/search/rfc2822) and 822 > ... > > Should be 2822, obviously. Pushed in your name at: https://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v8.30-59-g6201125 cheers, Pádraig
bug#34447: `pwd` doesn't show real working directory if directory is renamed by another session
Hi, I found that if a session's working directory is renamed or moved, `pwd` doesn't show the real working directory. Example: Session 1: ``` ~/ $ mkdir test ~/ $ cd test ~/test $ touch file ``` Session 2: ``` ~/ $ mv test test_2 ~/ $ mkdir test ~/ $ cd test ~/ $ touch file2 ~/ $ ls file2 ~/ $ ``` Session 1 (still running during session 2): ``` ~/test $ ls file ~/test $ pwd /Users//test ~/test $ realpath file /Users//test_2/file ~/test $ realpath nonExistenFile /Users//test_2/nonExistenFile ``` It seems that `realpath` does show the updated path, but `pwd` doesn't Tested on MacOS (10.14.3) and Ubuntu 16.04 / 18.04 Thanks, Chris
bug#33644: [PATCH] cp --preserve=xattr: preserve NFSv4 ACL extended attributes
On 11/02/19 03:50, Kamil Dudka wrote:
> On Monday, February 11, 2019 6:07:18 AM CET Pádraig Brady wrote:
>> On 06/12/18 05:08, Kamil Dudka wrote:
>>> ... which cannot be preserved by other means
>>>
>>> Bug: https://bugzilla.redhat.com/1031423#c4
>>> ---
>>>
>>> src/copy.c | 22 +-
>>> 1 file changed, 17 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/src/copy.c b/src/copy.c
>>> index 3221b9997..754c5e1aa 100644
>>> --- a/src/copy.c
>>> +++ b/src/copy.c
>>> @@ -640,6 +640,17 @@ copy_attr_free (struct error_context *ctx _GL_UNUSED,
>>>
>>> {
>>> }
>>>
>>> +/* Include NFSv4 ACL extended attributes, which cannot be preserved by
>>> + other means. Otherwise honor attributes configured for exclusion
>>> + in /etc/xattr.conf. Return zero to skip. */
>>> +static int
>>> +check_not_nfs4_acl (const char *name, struct error_context *ctx)
>>> +{
>>> + return attr_copy_check_permissions(name, ctx)
>>> + || !STRNCMP_LIT (name, "system.nfs4_acl")
>>> + || !STRNCMP_LIT (name, "system.nfs4acl");
>>> +}
>>> +
>>>
>>> /* Exclude SELinux extended attributes that are otherwise handled,
>>>
>>> and are problematic to copy again. Also honor attributes
>>> configured for exclusion in /etc/xattr.conf.
>>>
>>> @@ -649,7 +660,7 @@ static int
>>>
>>> check_selinux_attr (const char *name, struct error_context *ctx)
>>> {
>>>
>>>return STRNCMP_LIT (name, "security.selinux")
>>>
>>> - && attr_copy_check_permissions (name, ctx);
>>> + && check_not_nfs4_acl (name, ctx);
>>>
>>> }
>>>
>>> /* If positive SRC_FD and DST_FD descriptors are passed,
>>>
>>> @@ -663,6 +674,9 @@ copy_attr (char const *src_path, int src_fd,
>>>
>>>bool all_errors = (!x->data_copy_required ||
>>>x->require_preserve_xattr);
>>>bool some_errors = (!all_errors && !x->reduce_diagnostics);
>>>bool selinux_done = (x->preserve_security_context ||
>>>x->set_security_context);>
>>> + int (*check) (const char *, struct error_context *) = (selinux_done)
>>> +? check_selinux_attr
>>> +: check_not_nfs4_acl;
>>>
>>>struct error_context ctx =
>>>{
>>>
>>> .error = all_errors ? copy_attr_allerror : copy_attr_error,
>>>
>>> @@ -670,12 +684,10 @@ copy_attr (char const *src_path, int src_fd,
>>>
>>> .quote_free = copy_attr_free
>>>
>>>};
>>>if (0 <= src_fd && 0 <= dst_fd)
>>>
>>> -ret = attr_copy_fd (src_path, src_fd, dst_path, dst_fd,
>>> -selinux_done ? check_selinux_attr : NULL,
>>> +ret = attr_copy_fd (src_path, src_fd, dst_path, dst_fd, check,
>>>
>>> (all_errors || some_errors ? &ctx : NULL));
>>>
>>>else
>>>
>>> -ret = attr_copy_file (src_path, dst_path,
>>> - selinux_done ? check_selinux_attr : NULL,
>>> +ret = attr_copy_file (src_path, dst_path, check,
>>>
>>>(all_errors || some_errors ? &ctx : NULL));
>>>
>>>return ret == 0;
>>
>> This patch is confusing to read, though looks functional.
>
> I can submit deduplication of the `selinux_done ? check_selinux_attr : NULL`
> code as a separate patch if you prefer it.
>
>> It's clearer of you rename check_not_nfs4_acl() to
>> check_but_allow_nfs4_acl().
>
> Fine by me.
>
>> So in summary, any xattr in /etc/xattr.conf is _not_ copied.
>> You want to essentially ignore the nfs4 entries in that config file.
>> So why not just remove the entries from that file?
>
> See how xattr.conf is documented:
>
> # Actions:
> # permissions - copy when trying to preserve permissions.
> # skip - do not copy.
>
> The fact that coreutils handles `persmissions` equally as `skip` is IMO a
> problem of coreutils, not a problem of xattr.conf.
>
>> Is that something that could be done in attr.git?
>
> I think that the information in xattr.conf is correct. system.nfs4_acl is
> really an attribute one wants to copy when trying to preserve permissions.
Right. What I was getting at was attr_copy_file() from libattr seems
to skip all entries in xattr.conf by default. I need to dig in to
see what's preserving system.posix_acl_access (these might be
implicitly generated upon attr reading for example).
My question was why does coreutils need to explicitly handle
the nfs4 acls if it doesn't need to handle the posix ones.
I'm not saying the patch is wrong at all,
I'm just not seeing the full picture.
>
>> Why would one want to treat nfs4 attrs differently to the posix_acl_access
>> attrs?
>
> It was written in the commit message. One can use `cp --preserve=mode`
> to preserve POSIX ACLs whereas the only way to preserve NFSv4 ACLs was
> `cp --preserve=xattr`.
>
>> thanks,
>> Pádraig.
>
> On Monday, February 11, 2019 6:21:49 AM CET Pádraig Brady wrote:
>> BTW is there anything interesting behind this paywall I can't access?
>> https://access.redhat.com/solutions/115043
>
> It just says that `cp a b` does not preserve NFSv4 ACLs whereas `cp -a a
bug#34438: [8.30, info] doc error in -R
Hi, There's a small bug in doc here: ‘-R’ ‘--rfc-email’ ... This format conforms to Internet RFCs 5322 (https://tools.ietf.org/search/rfc5322), 822 ^ (https://tools.ietf.org/search/rfc2822) and 822 ... Should be 2822, obviously. Thanks.
bug#33644: [PATCH] cp --preserve=xattr: preserve NFSv4 ACL extended attributes
On Monday, February 11, 2019 6:07:18 AM CET Pádraig Brady wrote:
> On 06/12/18 05:08, Kamil Dudka wrote:
> > ... which cannot be preserved by other means
> >
> > Bug: https://bugzilla.redhat.com/1031423#c4
> > ---
> >
> > src/copy.c | 22 +-
> > 1 file changed, 17 insertions(+), 5 deletions(-)
> >
> > diff --git a/src/copy.c b/src/copy.c
> > index 3221b9997..754c5e1aa 100644
> > --- a/src/copy.c
> > +++ b/src/copy.c
> > @@ -640,6 +640,17 @@ copy_attr_free (struct error_context *ctx _GL_UNUSED,
> >
> > {
> > }
> >
> > +/* Include NFSv4 ACL extended attributes, which cannot be preserved by
> > + other means. Otherwise honor attributes configured for exclusion
> > + in /etc/xattr.conf. Return zero to skip. */
> > +static int
> > +check_not_nfs4_acl (const char *name, struct error_context *ctx)
> > +{
> > + return attr_copy_check_permissions(name, ctx)
> > + || !STRNCMP_LIT (name, "system.nfs4_acl")
> > + || !STRNCMP_LIT (name, "system.nfs4acl");
> > +}
> > +
> >
> > /* Exclude SELinux extended attributes that are otherwise handled,
> >
> > and are problematic to copy again. Also honor attributes
> > configured for exclusion in /etc/xattr.conf.
> >
> > @@ -649,7 +660,7 @@ static int
> >
> > check_selinux_attr (const char *name, struct error_context *ctx)
> > {
> >
> >return STRNCMP_LIT (name, "security.selinux")
> >
> > - && attr_copy_check_permissions (name, ctx);
> > + && check_not_nfs4_acl (name, ctx);
> >
> > }
> >
> > /* If positive SRC_FD and DST_FD descriptors are passed,
> >
> > @@ -663,6 +674,9 @@ copy_attr (char const *src_path, int src_fd,
> >
> >bool all_errors = (!x->data_copy_required ||
> >x->require_preserve_xattr);
> >bool some_errors = (!all_errors && !x->reduce_diagnostics);
> >bool selinux_done = (x->preserve_security_context ||
> >x->set_security_context);>
> > + int (*check) (const char *, struct error_context *) = (selinux_done)
> > +? check_selinux_attr
> > +: check_not_nfs4_acl;
> >
> >struct error_context ctx =
> >{
> >
> > .error = all_errors ? copy_attr_allerror : copy_attr_error,
> >
> > @@ -670,12 +684,10 @@ copy_attr (char const *src_path, int src_fd,
> >
> > .quote_free = copy_attr_free
> >
> >};
> >if (0 <= src_fd && 0 <= dst_fd)
> >
> > -ret = attr_copy_fd (src_path, src_fd, dst_path, dst_fd,
> > -selinux_done ? check_selinux_attr : NULL,
> > +ret = attr_copy_fd (src_path, src_fd, dst_path, dst_fd, check,
> >
> > (all_errors || some_errors ? &ctx : NULL));
> >
> >else
> >
> > -ret = attr_copy_file (src_path, dst_path,
> > - selinux_done ? check_selinux_attr : NULL,
> > +ret = attr_copy_file (src_path, dst_path, check,
> >
> >(all_errors || some_errors ? &ctx : NULL));
> >
> >return ret == 0;
>
> This patch is confusing to read, though looks functional.
I can submit deduplication of the `selinux_done ? check_selinux_attr : NULL`
code as a separate patch if you prefer it.
> It's clearer of you rename check_not_nfs4_acl() to
> check_but_allow_nfs4_acl().
Fine by me.
> So in summary, any xattr in /etc/xattr.conf is _not_ copied.
> You want to essentially ignore the nfs4 entries in that config file.
> So why not just remove the entries from that file?
See how xattr.conf is documented:
# Actions:
# permissions - copy when trying to preserve permissions.
# skip - do not copy.
The fact that coreutils handles `persmissions` equally as `skip` is IMO a
problem of coreutils, not a problem of xattr.conf.
> Is that something that could be done in attr.git?
I think that the information in xattr.conf is correct. system.nfs4_acl is
really an attribute one wants to copy when trying to preserve permissions.
> Why would one want to treat nfs4 attrs differently to the posix_acl_access
> attrs?
It was written in the commit message. One can use `cp --preserve=mode`
to preserve POSIX ACLs whereas the only way to preserve NFSv4 ACLs was
`cp --preserve=xattr`.
> thanks,
> Pádraig.
On Monday, February 11, 2019 6:21:49 AM CET Pádraig Brady wrote:
> BTW is there anything interesting behind this paywall I can't access?
> https://access.redhat.com/solutions/115043
It just says that `cp a b` does not preserve NFSv4 ACLs whereas `cp -a a b`,
`cp --preserve=all a b`, or `cp --preserve=xattr a b` does. Unfortunately,
this is currently true only for Red Hat Enterprise Linux.
Kamil
bug#12400: rmdir runs "amok", users "curse" GNU...(as rmdir has no option to stay on 1 file system)...
On 2/10/2019 1:52 PM, Bob Proulx wrote: > L A Walsh wrote: If you want a recursive option why not use 'rm -rf'? >> rmdir already provides a recursive delete that can cross >> file system boundaries > > Please provide an example. Something small. Something concrete. > Please include the version of rmdir. As near as I can tell the rmdir case derives from the similar case (assuming -x as shorthand for --onefilesystem), under 'rm -frx foo/*' or 'cd foo && rm -frx *' that was suggested as a replacement for the desired rm -frx foo/. or 'cd foo && rm -frx .' The first two forms of rm using '*' have no limit on the number of file systems that can be affected. Only the form 'foo/.' or '.' when used with --one-filesystem will be actually limited to one-file-system. If rmdir ever had a related but (now can have more so with -p), it could also affect multiple dirs with 'rmdir foo/*' Now you can't claim '*' is a somehow disallowed as it was suggested as a workaround for disallowing rm -frx foo/. But any form with 'rm' or rmdir can unsafely affect multiple file systems on multiple systems, as users are told to use shell-wildcards to make up for being unable to specify the top level inside dir for deletion. The reason things proably got so chaotic is that when it as suggested that '*' be used with rm -frx *, one-filesystem was no longer just 1 file system. 1) pray tell, why would it be called one file system when its not? Now it's one-filesystem / root arg? Uh huh. That sounds more than a bit specious to me. 2) if 'rm' really limited its deletes to 1 file system (ensuring all it's cmd line args were on the same file system, Then the same feature can be applied to rmdir to prevent it going from touching different file systems in 1 command. Of couse with -p as it back tracks, each back track and imply a change of file system. I can't find the original posts, but early comments applied to 'rm'. Some people seem to change titles of bugs without really understanding what the root bug was about, so the fact that something has rmdir in the title now doesn't really mean the original was about rmdir. Might want to examine that policy so things won't get as confusing -- adding on to a title in a separate field (gnu-summary), seems like it might be less consusing that changing the original title. That's my best guess at what this is about, but trying to recall details where my original didn't seem to get posted back to me (I thought it did, maybe things have chnaged in 6 years?). -l Since to delete all files under a directory with something like (assuming '-x' for '--one-filesystem') rm -frx * or rmdir * can all delete things on multiple file systems. Note, multiple responders, in discussing rm -frx > > Something like: > > mkdir testdir testdir/dir1 testdir/dir2 testdir/dir2/dir3 > rmdir --recursive testdir/dir2 > rmdir --version > > Include all input and output verbatim. For clarity do not use shell > file glob wildcards because that is a dependence upon a specific > command line shell and the shell's configuration. > >> dir1->dir2->dir3 >> >> dir1 is on 1 file system, dir 2 is on another and dir 3 can be on another. > > GNU Coreutils rmdir does not provide a recursive delete option. > Therefore one can only assume that the rmdir you are referring to is a > different rmdir from a different project. > > I specifically asked if you were using the rmdir --parents option but > my message was the only mention of --parents in this entire ticket and > in subsequent responses your messages also did not mention it. > Therefore I can only assume that there is no --parents option being > used here. > There is always 'find' with the -delete option. But regardless there has been the find -exec option. >> true -- so why should 'rm' protect against crossing boundaries >> deleting '/' or everything under '.' when there is find? >> >> find is the obvious solution you are saying, so all that checking in >> rm should be removed, as it is inconsistent with rmdir that can >> cross boundaries. > > My mention of 'find' was really a simple statement about alternatives > when programmatic needs are desired. Because 'find' is the swiss army > chainsaw for directory traversal. I didn't mean to derail the > discussion there. But if it is to be derailed then 'find' is the best > choice when needing a specific set of programmatic requirements for > directory traversal. The other utilities that have simpler > capabilities are the distractions. But in theory this bug ticket was > about 'rmdir'. > >> As for closing something not addressed for 6 years while the problem >> has grown worse -- (rmdir didnt' used to have a recursive delete), doesn't >> seem a great way to judge whether or not a bug is valid or not . > > GNU Coreutils rmdir does not provide a recursive delete option. > > This bug report so far has contained conflicting complaints to the > point that it has not been us
