bug#29568: Bug in find, or my mistake ?

[f0rhum]

Hi
find -version
find (GNU findutils) 4.4.2

I issued this command to remove all files "*_original" from parent tree :
/find .. iname "*_original" -delete/
as you see I forgot the minus sign before /iname/.
The result was all regular files were deleted, just leaving behind empty
directories (I don't really know why dirs remained, maybe because it is
a synchronised folder with some exclusions that prevented remote
deletion and the local were created back).
Is it because /iname/ and /"*_original"/ are both seen as EXPRESSIONS
that always return true so that -delete applies to .. and content as a
whole ?

Thanks
//

bug#28890: Painfully slow: DU.exe -Ssb %CD%

[f0rhum]

man ncdu ? NCurses disk usage

Le 18/10/2017 à 14:12, Gavin Holt a écrit :
> Hi
>
> I am trying to use cmd batch file to list the size of all directories
> in my roaming user profile - so I an clean it out.
>
> DU.exe works well and gives me the exact output I want - the sum of
> the size of the files in each directory EXCLUDING subdirectories. e.g.
>
> P:\MyPrograms\EDITORS\Scite>du -Ssb %CD%
> 2641767 P:\MyPrograms\EDITORS\Scite
>
> P:\MyPrograms\EDITORS\Scite\tools>du -Ssb %CD%
> 8834439 P:\MyPrograms\EDITORS\Scite\tools
>
> I would use a for loop to iterate over all the directories, but
> testing with a single directory shows this command to be painfully
> slow.
> (dir /AD /B /S %USERPROFILE%)
>
> Is there any way to optimize the DU function or an alternative you can
> suggest that gives the identical output.
>
> I did read the link below - but the output is not what I wanted.
>
> https://stackoverflow.com/questions/30513287/faster-way-to-get-folder-size-with-batch-script
>
> Kind Regards
>
> Gavin
>
>
>

bug#27488: du -tX -t-Y won't exclude or select an interval of SIZE

[f0rhum]

On 26/06/2017 at 09:00, Pádraig Brady wrote :
> On 25/06/17 11:08, f0rhum wrote:
>> I know man clearly states "exclude entries smaller  than  SIZE  if 
>> positive,  or entries greater than..."
>> I don't know if it is a restriction in my 8.21, but only the last -t
>> option in my command line applies.
>> If not, maybe a feature could allow this like du -t3G-5G or -t3G -t-5G
>> could show dirs from 3 to 5G
>> and -t-3G5G or -t5G -t-3G would show all others.
>> Okay, I guess this would be an opened door for guys requesting more than
>> one intervall ;)
> Maybe, though it would complicate things,
> and make it incompat with older -t implementations.
> I'm not sure there is enough need for this?
>
> cheers,
> Pádraig
>
>
>
>
Incompat with elder implementations could be strictly preserved when
using a single -t. Man neither info coreutils state only the last -t is
taken into account.
Okay don't worry, I'll have to find how to script this, as I also need
to exclude directories that contain a 0 byte flag file.
Good week Pádraig and collegues, and thanks for your great work.

Fabrice

bug#27488: du -tX -t-Y won't exclude or select an interval of SIZE

[f0rhum]

I know man clearly states "exclude entries smaller  than  SIZE  if 
positive,  or entries greater than..."
I don't know if it is a restriction in my 8.21, but only the last -t
option in my command line applies.
If not, maybe a feature could allow this like du -t3G-5G or -t3G -t-5G
could show dirs from 3 to 5G
and -t-3G5G or -t5G -t-3G would show all others.
Okay, I guess this would be an opened door for guys requesting more than
one intervall ;)

bug#25475: tail -f behaviour

[f0rhum]

Le 19/01/2017 à 01:05, Bernhard Voelker wrote :
> tag 25475 notabug
> close 25475
> stop
>
>
> On 01/19/2017 12:44 AM, f0rhum wrote:
>> deleted (then sed -i '$ d' $LOGF;), then immediately 3 + 43 printed
> ^^
>
> That's the reason: "sed -i" opens a new, temporary file and filters the
> original content from 'file' to the new one; finally, it renames the
> temporary file to the original file name:
>
>   $ strace -e open,read,write,rename sed -i '$ d' file
>   ...
>   open("file", O_RDONLY)  = 3
>   open("./sedLPtf2x", O_RDWR|O_CREAT|O_EXCL, 0600) = 4
>   read(3, "xxx\n"..., 4096) = 953
>   write(4, "xxx\n", 4)  = 4
>   ...
>   read(3, "", 4096)   = 0
>   read(3, "", 4096)   = 0
>   rename("./sedLPtf2x", "file")   = 0
>   +++ exited with 0 +++
>
> The file has the same name, but the file descriptor that tail opened
> at startup is a different one.  You can also see that the inode number
> of the file changes:
>
>   $ ls -logi file
>   5770837 -rw-r--r-- 1 817 Jan 19 00:54 file
>
>   $ sed -i '$ d' file
>
>   $ ls -logi file
>   5774048 -rw-r--r-- 1 751 Jan 19 01:00 file
>
> As "tail -f" means to follow the original file descriptor, it is
> not supposed to follow the new file (which has the same name):
>
>   -f, --follow[={name|descriptor}]
>output appended data as the file grows;
>  an absent option argument means 'descriptor'
>
> As such, there is no bug in tail; therefore I'm marking it as such,
> and close this issue in our bug tracker.
>
> Have a nice day,
> Berny
Thank you very much Bernie
I won you taught me huge knowledge (descriptor and related, that was
mysterious to me when reading the man)
Thanks too to all you GNU enthusiasts heavy workers
 

bug#25475: tail -f behaviour

[f0rhum]

tail -fn20 -s30 file
...
2017-01-18 22:55:00  10  0V18  +1C 0A00 500mA 11V70  20% 2A30 11861
DateHeure   Mes. Vpan. Tmp.  Ich.  Conso   Vbat.   SoC  Sta 
Vin mV
2017-01-18 23:00:01  10  0V17  +1C 0A00 500mA 11V71  19% 2A30 11879
2017-01-18 23:05:00  10  0V17  +0C 0A00 480mA 11V71  20% 2A30 11868
2017-01-18 23:10:00  10  0V18  +0C 0A00 500mA 11V70  19% 2A30 11865
2017-01-18 23:15:00  10  0V16  +0C 0A00 510mA 11V69  19% 2A30 11832
  --> Vbat<11V70: Delestage automatique de 9h08mn
2017-01-18 23:20:21 Controleur inaccessible
2017-01-18 23:25:21 Controleur inaccessible
^C
tail -fn20 -s30 file
...
2017-01-18 22:55:00  10  0V18  +0C 0A00 500mA 11V70  20% 2A30 11861
DateHeure   Mes. Vpan. Tmp.  Ich.  Conso   Vbat.   SoC  Sta 
Vin mV
2017-01-18 23:00:01  10  0V17  +1C 0A00 500mA 11V71  19% 2A30 11879
2017-01-18 23:05:00  10  0V17  +0C 0A00 480mA 11V71  20% 2A30 11868
2017-01-18 23:10:00  10  0V18  +0C 0A00 500mA 11V70  19% 2A30 11865
2017-01-18 23:15:00  10  0V16  +0C 0A00 510mA 11V69  19% 2A30 11832
  --> Vbat<11V70: Delestage automatique de 9h08mn
2017-01-18 23:20:21 Controleur inaccessible
...
2017-01-19 00:10:04 Controleur inaccessible

For the 2 above, I didn't delete any line above. Only the line 23:25:21
in the first was replaced by my script with
...
23:30:xx   <--- which in turn was updated by a new similar messages
until a different message happens (note here this is an additionnal line)
I didn't have the idea that "file grows" can have 2 meaning : grows in
bytes, or grows in line numbers. Whatever, a new line was added between
iterations (one deleted then immediately 2 added), and 3 bytes added (43
deleted (then sed -i '$ d' $LOGF;), then immediately 3 + 43 printed
immediately in a single write (help of printf "...\n%s Controleur
inaccessible\n" "`date "+%F %X"`" >>$LOGF )

I must also clarify something : this not an issue for me, I just wanted
to share what I discovered.
I just discovered -f was great live help while tracking bugs in my script.

Bye bye

bug#25475: tail -f behaviour

[f0rhum]

Hi
This is about tail v5.97
I have a log file that is updated every 5mn, a timestamped message being
appended to a new line at the end
On the third time an indentical message would be writen, the last line
is replaced by "..." then the message is writen

Tracking changes with tail -f stops after this, which may be intended
behaviour as man states "as the file grows".

Although, when pruning a bunch of lines from the head of the file, then a
yet running tracking still won't update even the file size grows, like if the 
file size was
grabbed on the very beginning of the command and never updated on each
iteration.

To be honest, I didn't try to see what happens if I prune a single line
and see what the next 2nd and further iterations show.

bug#23302: mention what are nonprinting characters

[f0rhum]

As per https://en.wikipedia.org/wiki/ASCII#ASCII_control_characters

Le 16/04/2016 21:50, 積丹尼 Dan Jacobson a écrit :
> In (info "(coreutils) Concept index") there are several items that talk
> about nonprinting characters.
>
> Well on each definition be sure to have a blue word link:: to a passage
> about which characters are nonprinting, lest the user think e.g.,
> SPC (' ') is nonprinting.
>
>
>

bug#22567: Factoring 38 nines

[f0rhum]

Discovering this command, I submit a small mis-translation for french:
"factor --version
factor (GNU coreutils) 8.21
Copyright © 2013 Free Software Foundation, Inc.
License GPLv3+ : GNU GPL version 3 ou ultérieure

C'est logiciel libre..."

Should be "C'est ***un*** logiciel libre..." or "Ceci est ***un*** logiciel 
libre..."

bug#21325: ls : feature request --width=zero

[f0rhum]

Le 23/08/2015 23:11, Stephane Chazelas a écrit :
 2015-08-23 13:26:35 +0200, Erik Auerswald:
 Hi,

 On Sat, Aug 22, 2015 at 08:58:01PM -0700, Paul Eggert wrote:
 Pádraig Brady wrote:
 Also base64 -w0 has similar meaning.
 I didn't know that, but I don't like that either.  Utilities should
 use an explicit representation for infinity, if that's what they
 need.  'Inf', say.

 In the meantime, the patch that I installed is helpful even if we
 later add an explicit representation of infinity.
 Using 0 to disable a length or width limit is quite common with networking
 gear. I do not know any example requiring a keyword like Inf, neither
 UNIX (like) nor other CLIs.
 [...]

 Anything using strtod() to parse numbers should understand inf
 or infinity (with any vAriATion on the case).

 That's the case of GNU sleep for instance.

 That doesn't apply to integers though.

I'm not involved, but just a suggestion if no one tought about this: why
not use w-1 ?

bug#18748: cp doesn't behaves as mkdir and touch when a default acl exists.

[f0rhum]

 and therefore, there's nothing we can do about it without
 either violating POSIX permission copying or adding several ACL-related
 calls although the user told us not to do so.
 Did I miss something?

...although the user told us not to do so...

Hi Bernie
I'm still puzzled 
So do you mean the only way not to violate POSIX permissions is to respect 
what the user tells to do?
Then let's get a look at what the user tells:
First, use POSIX (basic) permissions
THEN, add ACL support (to be read below extended ACL support)

Reverting the sequence is pure non sense (but if I first choose a system with 
native ACL support like NT), so if the 2nd step is a violation of the 1st one, 
then the 2nd one (violating) would just made be impossible so that said ACL 
support concept doesn't even exist.

ACL support being currently advertised, I feel I legitimately want to see it 
applied as superseding the basic permissions set where (such or such tree) 
***me-the-user*** want this superset to apply.

If I'm wrong, at least ACL would be renamed to ACR (Access Control 
Restrictions) according to the current behaviour with cp/mv.

Fabrice-the-user

bug#18937: chmod ???? bug?

[f0rhum]

Le 04/11/2014 18:47, Bob Proulx a écrit :
 Plato wrote:
 After using chmod
  chmod -R 644 /media/plato/mountedpartition/ (I see I forgot the * 
 at the end)
 That is a problematic command regardless of the '*' at the end or
 not.  If any of the arguments is a directory then it will set the
 directory permission to 644 as specified.  But directories need the
 'x' bit (execute permission) set as well.

 The above command will remove the execute bit from
 /media/plato/mountedpartition and then fail to search below it due to
 permission problems.  It will then leave the directory in an unhappy
 state.

  ls -l
 listing has all entry's like these:
  First a list like this of every file and folder
  ls: cannot access /media/plato/mountedpartition/justafiile.txt: 
 Permission denied
 That is correct when the execute permission is removed from a directory.

 When I do
  sudo ls Files
 I get a listing of the contents of files as expected.
 This is because file mode bits only apply to non-root access.  Root is
 the superuser and always has permission regardless of the file mode
 bits.  Root always has access regardless of permissions.

 Is this a bug?
 No.  It is doing exactly what you told it to do.

 Try this:

   ls -ld /media/plato/mountedpartition

 The -d option will tell ls to show the argument itself instead of
 showing the contents of the directory.  With that you will see
 something like this mode bits: drw-r--r-- but directories need to have
 the x bit there too like drwxrwxr-x typically.

 It was not my intention to get this. I do not know how to get it back to 
 what it was.
 I tried it on a single file with
  chmod 644 justafile.txt
 but that did not solve it. Any ideas?
 After removing the execute bit from the directory you simply must add
 the execute bit back to the directory.  It will probably be enough to
 do this using symbolic modes.

   chmod a+x /media/plato/mountedpartition

 In the old numeric form, combined with your previous 644, this would
 be similar to:

   chmod 755 /media/plato/mountedpartition

 Do not use the -R option with numeric arguments such as 644 because
 the numeric mode will be recursively applied across directories.  That
 is almost never what you want.  If using the -R option it is safer to
 use the symbolic modes such as go-w.

 Since this is all expected behavior I am going to go ahead and close
 this bug.  However please continue the discussion here in the bug
 log.  Any replies are still seen and discussed by the group.

 Bob



chmod -R u=rwX,g=rwX[s],o=[---|rX|rwX] /media/plato/mountedpartition/
(no need the *, implied by -R)

bug#18937: chmod ???? bug?

[f0rhum]

chmod -R u=rwX,g=rwX[s],o=[---|rX|rwX] /media/plato/mountedpartition/
(no need the *, implied by -R)

bug#5926: feature request: mv -p to create missing target dir

[f0rhum]

 I mean why wasn't refused cp -p request, saying just use mkdir first.

 There seems to be a good deal of confusion here, as cp -p has nothing to do 
 with mkdir -p.

Oooops, sorry, I meant: why wasn't refused mkdir -p option request, saying 
just use ls and mkdir first?
Hmmm, ok, I see they are both about creating dirs, but aren't mkdir, cp, mv, 
touch... all involved in creating links in a file system? Hmmm... It seems I 
triggered an endless loop in my own mind: confusion was yet there. Let's call 
this ignorance, lazziness. Mum!

bug#5926: feature request: mv -p to create missing target dir

[f0rhum]

 The mv command causes an atomic rename(2) to occur if on the same file
 system.  That is not possible when using cp + rm.  Therefore mv is
 required.
Hi Bob.
I am just trying to understand why this very request is refused with
the argument small is beautiful, when the -p was accepted for cp:
I mean why wasn't refused cp -p request, saying just use mkdir first.
This seems unfair for mv to be refused the ease of use cp was offered.
Maybe I have a problem with understanding this atomic word
which also stunned myself in iptables documentation. 

 If mv'ing a file from one file system to another it is impossible to
 have an atomic rename().  In that case mv falls back to effectively cp
 plus rm.  That is mentioned in the mv documentation.
The same You have to know if the parent exists argument that was opposed
to this request could have also been opposed: You have to know if you are
moving in the same file system or an other,
so we stick to rename+cp+rm, no need for mv at all, small is beautiful,
do one thing and do it well.

That's not to argue. Just coming to GNU since 6 years from closed source
OSes where nobody wouldn't even have the idea to ask why this-and-that, I
realize here I can ask why, e.g. why we haven't some kind of uniformity in
commands parameters --long and -short for various commands. This would be
a great help for average users. Somebody once replied to me it is because
many different people work(ed) on these commands, at different time Just
a pure fact we have to live with. Is it the same inside the coreutils 
team too?

Bye bye

Fabrice

bug#18748: cp doesn't behaves as mkdir and touch when a default acl exists.

[f0rhum]

Hi Bob,
Thank you for this detailed answer

 I posted ...in
 http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8527...
 http://lists.nongnu.org/archive/html/acl-devel/2014-10/msg1.html
 .. I ask ...if we could have a question for this in the coreutils FAQ...
 
 One of the problems I personally would have in writing an ACL entry is
 that I personally don't use ACLs and therefore do not know them well
 enough to write a good FAQ entry that covers ACLs.  I don't have the
 experience with them.  If you (or anyone else) is using ACLs and knows
 them well then would you consider writing up an FAQ entry and
 submitting it?  The best time to documentation is when you are
 learning something because that is when you still remember what you
 needed to know about it.

Well Bob, I'm too newby in GNU/Linux to dare writing any documentation.
Although, and yet a lot of tips-'n-tricks on acl exists on the web,
they all lack the GNU philosophy background we find in the coreutils FAQ. 
And the sad thing is that Internet is the place where I find so much people
ready to help, but who are not sure... because they do not use.  Not using
alc yourself, I really appreciate you do not try to answer.  I must confess
I can't always curb myself.

 cool working mkdir and touch? These two were made compliant with default
 extended acls, so why not cp and mv?

 I don't know.  Why not?  You tell me.  What is the problem? You
 haven't said what the problem is.  What are you seeing?  Can you
 provide a small test case that illustrates whatever problem you are
 talking about?

 Are you talking about Bug#8527[1].  If so did you intend to open a new
 bug report here?  Perhaps you intended to add a comment to that bug
 ticket?  If so then it would have been better simply to mail that bug
 ticket instead of creating a new one. If so we will merge this ticket
 with that one and continue the discussion there.
 [1] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8527.

Yes Bob, I posted a case there (*).  And I got feedback, and even a workaround.
Unfortunately, newb I am, and I went yet again stuck, namely at
install time (I walked the compilation step, but newb I am and I can't say
if the log states anything wrong).
Furthermore, cp being a core utility, I'm afraid I break my system if I do 
something
wrong leaving it without a cp feature probably pre-required to reinstall the 
genuine one.
Furfurthermomore, when I posted this workaround in the bug tracker to which
I first submitted the ~bug~, a guy discouraged me using it (spartan dangerous)
because of a foo ; rm -rf tilde thing that might fall from the skies.  With no
reply to him from a gureex, I dared my own newb's reply which remained
huheeded ( https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1376443 ).
And then I'm pretty sure you know/remember that make is a swearword for
an average user, surely ruder than acl is if we consider the underlying 
complexity
of each other, isn't it?
(* I realize this is not of good practice to appends one's issue to
another existing one.  Again, I didn't want to flood with my big shoes and 
(wrongly?) thought it would be more constructive if ~related~ issues were
together.)

So, as I didn't want to flood the bug list here, and still being stuck
after I re-re-read and re-re-re-read all I could find (man, info, drafts...)
and went back to the coreutils faq (hoping I missed something of huge 
obviousness),
where I found this (after I searched again for acl and permissions):

...If you still don’t find a suitable answer,
consider posting the question to the bug list. 
Well, I didn't want to flood, I'm advised too :/ ... so I did.
Not really sure I hit a bug or my own nullity, I think asking
a faq item in coreutils was then the best place for others in my breed
... unless I am a breed all on my own :), but I don't think so.

If I went on posting here atgnu, it is because I feel my issue is of that kind
we call patate chaude in french: ubuntu, debian, gnu, savannah,
acl-develatgnu|nongnu.org... who wants the hot potatoe? ;) ... nobody?? OMR, 
did I
find another French Administration? :(  (Oh My Robespierre).


 If you just want general discussion please use coreuti...@gnu.org
 instead.  That is for general discussion.  It is a normal mailing
 list.  It is not a bug list and does not open a bug ticket each time.
 I think that might be where you intended to send this message.

Not really what I wanted... see above.  But as you advise, I'll do.


 the write permission. Gureeks are there to mitigate my imagination ;-)
 Michael Orlitzky (aka copyright sucks) already did such a job, so why
 not make room for him? (or maybe it's already a WIP?)
 At least the FAQ would explain why 2 groups is one too much, both in
 Unix and GNU philosophies.

 I am sorry but you have completely lost me there.

Sorry Bob, I know I often get the verbal diarrhea disease (call it
logorrhea if you want, I can't see a kind difference).  When I feel so
tired in searching, I'd rather like 

bug#5926: feature request: mv -p to create missing target dir

[f0rhum]

 ...is
mv 
 counter to The Unix Philosophy
?
  Small is
 beautiful.  Make each program do one thing well.  Choose portability
 over efficiency.  Use shell scripts to increase leverage and
 portability.

Would mv be discarded to the benefit of cp + rm?
Ok, I know we can't because mv also does in place rename. But when it's time to 
real move who does use cp then rm?

bug#18748: cp doesn't behaves as mkdir and touch when a default acl exists.

[f0rhum]

Hi gnu world
I posted a monologue about this in the list
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8527.
Another got more audience:
http://lists.nongnu.org/archive/html/acl-devel/2014-10/msg1.html
Well I read the coreutils FAQ and other the rtfm link, and I think it's
time to ask if we could have a question for this in the coreutils FAQ,
with the same brillant style than the ones for
http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Why-doesn_0027t-rm-_002dr-_002a_002epattern-recurse-like-it-should_003f
and
http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Why-don_0027t-the-utilities-have-built-in-directory-recursion_003f
, both refering to Unix philosophy, and both great light for
half-gnubies like me.
This one could be called Why don't we have automatic inheritance of
permissions with default extented acl?
This is a too long title, but too short to paint the landscape.
I know acl definition in the POSIX 1e draft 17 is a withdraw job.
I know acl is neither in coreutils nor even in GNU. I also now that the
N in GNU stands for not, so why not adopt the job further like yet
cool working mkdir and touch? These two were made compliant with default
extended acls, so why not cp and mv?
I also know sgid is a step on the path of inheritance, but not enough
when another group is needed.
I think (maybe I think bad) that cp and mv, at least on local, when run
__without-any-option-directly-related-to-the-permissions-mode-bits__ and
then meet a default acl set at the destination directory, would discard
they traditionnal behavior (that is re-writing permissions according to
umasked process and/or mount ones, not sure) and instead would rewrite
according only the said default acl as long as the process already has
the write permission. Gureeks are there to mitigate my imagination ;-)
Michael Orlitzky (aka copyright sucks) already did such a job, so why
not make room for him? (or maybe it's already a WIP?)
At least the FAQ would explain why 2 groups is one too much, both in
Unix and GNU philosophies.

Thank you

Fabrice

bug#8527: cp/mv in coreutils don't respect the default ACL of parent

[f0rhum]

And creations in the copied dir are OK:
Here the ~faulty~ acl for memory:
# file: srv/test/200402/
USER   me   rwx  rwx
user   reader   R-X  r-x
GROUP  writers  RWX  rwx
group  reader   R-X  r-x
group  writers  RWX  rwx
mask---  rwx
other   ---  ---

Then creations
me@pc:/srv$ mkdir test/200402/dir
me@pc:/srv$ touch test/200402/dir/file
   
me@pc:/srv$ getfacl -Rt test/200402/dir
# file: test/200402/dir
USER   me   rwx  rwx
user   reader   r-x  r-x
GROUP  writers  rwx  rwx
group  reader   r-x  r-x
group  writers  rwx  rwx
maskrwx  rwx
other   ---  ---

# file: test/200402/dir/file
USER   me   rw- 
user   reader   r-X 
GROUP  writers  rwX 
group  reader   r-X 
group  writers  rwX 
maskrw- 
other   ---

Are OK regard to the parent's correct Default mask, but only me as the USER 
can do this because other writers lost rwx on parent copy (200402 dir)

bug#8527: cp/mv in coreutils don't respect the default ACL of parent

[f0rhum]

Thank you Linda for extensive answer.
Just an additional info before I reply your questions: for my own tests I 
didn't use /tmp as target because the sticky bit could do something special 
(not sure). Instead I used /srv/test that I chown me:writers , set chmod -R 
u:rwX,g:srwX then setfacl --set as needed all this as root. The goal being 
having a group writers rwX, another group readers with rX on the tree and 
o:---, and ignore source perms if any.


 What file system and core utils are you using?

My target file system is ext4 (default mount options include acl and user_xattr 
, coreutils is 8.21  kernel is 3.13.0-36-generic #63-Ubuntu SMP Wed Sep 3 
21:30:07 UTC 2014 x86_64 GNU/Linux with embedded acl support out of the box).

 Are you using a file system that has alternate user-data forks
 or extended attributes that have them included by default?
 Or are you using a file system where they were added on as a super-user
 control'd option?  Have you tried copying them as root?

I know this:
from local, umask=0002
from ssh,   umask=0022
no cp aliases, I just need/use the default, i.e. do-not-preserve-perms
All my tests below are run locally. So I wrote a script that echoes each line:
sudo ~/acl.sh
0 mkdir -pv /srv/test
0 setfacl -bk /srv/test
0 rm -rf /srv/test/*
ownership of /srv/test was kept as me:writers
0 chown -Rv me:writers /srv/test
mode of /srv/test/ was changed from 2770 (rwxrws---) to  (-)
0 (removed all bits)
mode of /srv/test/ was changed from  (-) to 2770 (rwxrws---)
0 chmod -Rv u+rwX,g+srwX /srv/test
0 setfacl -R --set 
d:u::rwx,d:g::rwx,d:g:writers:rwx,d:u:reader:rx,d:g:reader:rx,d:o::---,d:m::rwx 
/srv/test
getfacl: remove first / out of absolute path names
# file: srv/test
USER   me   rwx  rwx
user   readerr-x
GROUP  writers  rwx  rwx
group  readerr-x
group  writers   rwx
mask rwx
other   ---  ---

0 setfacl -R --set 
u::rwX,g::rwX,u:reader:rX,g:writers:rwX,g:reader:rx,o::---,m::rwX /srv/test
getfacl: remove first / out of absolute path names
# file: srv/test
USER   me   rwx  rwx
user   reader   r-x  r-x
GROUP  writers  rwx  rwx
group  reader   r-x  r-x
group  writers  rwx  rwx
maskrwx  rwx
other   ---  ---

So at the moment this last command shows all is alright
   Now, let's copy 
me@pc:/srv$ cp -r /media/me/USPEED/200402/ /srv/test
me@pc:/srv$ getfacl -t /srv/test/200402/
getfacl: remove first / out of absolute path names
# file: srv/test/200402/
USER   me   rwx  rwx
user   reader   R-X  r-x
GROUP  writers  RWX  rwx
group  reader   R-X  r-x
group  writers  RWX  rwx
mask---  rwx
other   ---  ---

***problems begin: defaults ACL are kept OK (right perm column, ***
***but Access ACL are lost (capitalized in left column by -t are the denied 
perms because mask is lost, do not confuse with cap X in chmod)***
***only file owner can traverse, nobody else can)***

me@pc:/srv$ getfacl -t /srv/test/200402/P2220368.JPG 
getfacl: remove first / out of absolute path names
# file: srv/test/200402/P2220368.JPG
USER   me   rw- 
user   reader   r-X 
GROUP  writers  rWX 
group  reader   r-X 
group  writers  rWX 
maskr-- 
other   ---
*** Here one see writers lost the write perm, and reader could read if only he 
could traverse above***

Do the same by creation:
me@pc:/srv$ mkdir test/handdir
me@pc:/srv$ touch test/handdir/file
me@pc:/srv$ getfacl -Rt test/handdir/
# file: test/handdir/
USER   me   rwx  rwx
user   reader   r-x  r-x
GROUP  writers  rwx  rwx
group  reader   r-x  r-x
group  writers  rwx  rwx
maskrwx  rwx
other   ---  ---

# file: test/handdir//file
USER   me   rw- 
user   reader   r-X 
GROUP  writers  rwX 
group  reader   r-X 
group  writers  rwX 
maskrw- 
other   ---
***all is OK this way***








 The reason I ask, is that I just tried it and it appears to work:
 1) First the dir:
   cd /tmp
   llg -d /tmp
 drwxrwxrwt 25 root root 8192 Oct  7 02:21 /tmp/
   lsacl /tmp
 [u::rwx,g::rwx,o::rwx] /tmp   #default ACL from mode bits
 
 2) Create file with 'touch'
   touch x # new file
 Ishtar:/tmp llg x
 -rw-rw-r-- 1 law lawgroup 0 Oct  7 02:26 x
   lsacl
 [u::rw-,g::rw-,o::r--] x  #default ACL
 
 3) now I'll copy in a *directory* that has both types of ACL's on it, but
 not specifying that any permissions be copied:
 
   ll -d  /Media/Library/_artwork/test   #source
 drwxrwsr-x+ 2 10 Oct  7 02:33 

bug#8527: cp/mv in coreutils don't respect the default ACL of parent

[f0rhum]

I can confirm. Tests show that the parent folder ACL Default mask is not 
inherited as the ACL Access mask of the file|dir created by cp|mv.