bug-coreutils
[Top][All Lists]
Advanced

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

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


From: f0rhum
Subject: bug#18748: cp doesn't behaves as mkdir and touch when a default acl exists.
Date: Mon, 20 Oct 2014 18:21:11 +0200 (CEST)

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/msg00001.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 <at>gnu, it is because I feel my issue is of that kind
we call "patate chaude" in french: ubuntu, debian, gnu, savannah,
acl-devel<at>gnu|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 address@hidden
> 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 to be more precise, fearing the
single really skilled person in the world reading the post would
drop it as poorly decorated with juicy details.  Here how it plays: 
I ask a simple question, helper requires more details, I give...
then silence or equivalent... so I post details elsewhere until I find ... or 
not.

I only wanted to say this, that if we can't imagine that 2 groups (**)
with different permissions may need access to a same file|dir|tree, then
we don't need acl... at all.
This was a reference to my case in the bug #8527.
(** none of them being neither the object owner private group nor "others")

Bye bye

Maybe I'll read you in the discussion list? Let me know.

Fabrice





reply via email to

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