Re: ln can't backup directories

Bert Wesarg wrote: >> Hi Bert, >> >> Thanks for the patch! >> I'll review it Monday or Tuesday. > Thanks. > >> In the mean time, do you feel like writing the remaining >> parts of such a change? >> >> >>  - mention this in NEWS: put it under Changes in behavior or Improvements >> >>  - add tests o

Re: use of lchmod

Eric Blake wrote: ... > I'm thinking we should change things to be a bit more consistent, as part of > preparing copy.c to be rewritten to use fts, but I'm not sure which way to go. > Does anyone have preference? > > > If we go with POSIX, then: ... > > If we go with glibc behavior, then: > > The r

use of lchmod

POSIX does not require lchmod, and Linux does not supply it. On platforms that lack lchmod, symlinks always have the same default permissions, so the inability to change permissions is not a problem because the source that you would be copying has the same permissions (0777) as the newly create

Re: [PATCH] ls: support disabling colors on all subtypes

Pádraig Brady wrote: > I was trying to disable the green colors today in my ls listing > and noticed that if you do that the directories are shown > without color rather than falling back to the standard color > for directories (blue). > > The attached patch fixes that up. It deserves NEWS and a

Re: tail -f problem

Pádraig Brady wrote: > Jim Meyering wrote: >> >> diff --git a/src/tail.c b/src/tail.c >> @@ -1986,8 +1964,13 @@ main (int argc, char **argv) >>size_t n_viable = 0; >>for (i = 0; i < n_files; i++) >> { >> - if (STREQ (F[i].name, "-") && !F[i].ignore >> - && 0 <= F[i].fd &&

stat vs. "-"

In looking at Pádraig's report of a tail test failure with ksh, I wanted to see how ksh pipes differed from bash/zsh ones, by doing this: for i in sh zsh bash ksh; do printf "$i: "; $i -c ':|./stat --format=%F -';done sh: fifo zsh: fifo bash: fifo ksh: socket But couldn't, because stat didn't acc

Re: tail -f problem

Jim Meyering wrote: > > diff --git a/src/tail.c b/src/tail.c > @@ -1986,8 +1964,13 @@ main (int argc, char **argv) >size_t n_viable = 0; >for (i = 0; i < n_files; i++) > { > - if (STREQ (F[i].name, "-") && !F[i].ignore > - && 0 <= F[i].fd && S_ISFIFO (F[i].mode)) > +

Re: [PATCH] cp, mv: do preserve extended attributes even for read-only source files

Ondřej Vašík wrote: > Thanks for word tweaks and other patch-amending. I spotted one error - > initial value of access_changed was not changed to false when you > changed the name and logic from access_unchanged thanks Ondřej

Re: [PATCH] cp, mv: do preserve extended attributes even for read-only source files

Ondřej Vašík wrote: > Jim Meyering wrote: >> Ondřej Vašík wrote: >> > Pádraig Brady wrote: >> >> Yes I agree that the change is required. >> >> I've tweaked it so that the geteuid() syscall is only called >> >> if readonly files. Also I removed the error message on chmod failure >> >> as the user

Re: [PATCH] cp, mv: do preserve extended attributes even for read-only source files

Jim Meyering wrote: > Ondřej Vašík wrote: > > Pádraig Brady wrote: > >> Yes I agree that the change is required. > >> I've tweaked it so that the geteuid() syscall is only called > >> if readonly files. Also I removed the error message on chmod failure > >> as the user will still get an error messa

Re: [PATCH] cp, mv: do preserve extended attributes even for read-only source files

Ondřej Vašík wrote: > Pádraig Brady wrote: >> Yes I agree that the change is required. >> I've tweaked it so that the geteuid() syscall is only called >> if readonly files. Also I removed the error message on chmod failure >> as the user will still get an error message _if_ the copy_xattr fails. >>

Re: [PATCH] cp, mv: do preserve extended attributes even for read-only source files

Pádraig Brady wrote: > Yes I agree that the change is required. > I've tweaked it so that the geteuid() syscall is only called > if readonly files. Also I removed the error message on chmod failure > as the user will still get an error message _if_ the copy_xattr fails. > Also I ran it through inde