bug#61035: [PATCH] cp: improve help regarding ACLs
On Sunday, January 29, 2023 11:04:22 PM CET Paul Eggert wrote: > On 2023-01-29 03:06, Kamil Dudka wrote: > > On Wednesday, January 25, 2023 11:01:45 PM CET Paul Eggert wrote: > >> On 2023-01-25 13:56, Ondrej Valousek wrote: > >>> But it's not the same meaning. What I am trying to explain here is that > >>> > >>> Cp -p (or cp --preserve=mode) also retains ACLs. This fact is not > >>> obvious, but yet it's happening > >> Then I'm afraid I don't understand. In what sense do ACLs differ from > >> xattr here? > > As I understand it, `cp -p` now preserves ACLs but not xattr (unlike `cp > > -a`). > > OK, the light is slowly dawning on me. Though I'm still confused. > > Why are ACLs treated differently from extended attributes? Shouldn't the > two be treated the same (assuming they're both supported)? > > In other words, what's the underlying model and motivation here? It's > more important to document that, than to document little pieces of it. I cannot speak for Ondrej. My understanding is that ACLs can be seen as extension over permission bits whereas the extended attributes can store pretty much anything. I am not saying which approach is (more) correct though. Kamil
bug#61035: [PATCH] cp: improve help regarding ACLs
On 2023-01-29 03:06, Kamil Dudka wrote: On Wednesday, January 25, 2023 11:01:45 PM CET Paul Eggert wrote: On 2023-01-25 13:56, Ondrej Valousek wrote: But it's not the same meaning. What I am trying to explain here is that Cp -p (or cp --preserve=mode) also retains ACLs. This fact is not obvious, but yet it's happening Then I'm afraid I don't understand. In what sense do ACLs differ from xattr here? As I understand it, `cp -p` now preserves ACLs but not xattr (unlike `cp -a`). OK, the light is slowly dawning on me. Though I'm still confused. Why are ACLs treated differently from extended attributes? Shouldn't the two be treated the same (assuming they're both supported)? In other words, what's the underlying model and motivation here? It's more important to document that, than to document little pieces of it.
Re: RFC: cksum --base64/-b support
On Sun, Jan 29, 2023 at 12:40 PM Jim Meyering wrote: ... > - I'm inclined to work like the openbsd cksum and accept invocations > like "cksum -a sha1x" and "cksum -a sha1b". Any objection? Actually, I am now **disinclined** to implement this part. It'd make sense only if we were able to compute multiple checksums in a single invocation. Allowing that would require a fundamental redesign, which feels out of scope, at least initially.
RFC: cksum --base64/-b support
Hi Pádraig! Happy new year (belatedly ;-). Hope you're well. I'd like our generated announcements to be able to include base64-encoded checksums without having to recommend verifying them using openbsd's cksum, so... I've begun writing the code to add --base64/-b support for GNU cksum, prompted by this thread: https://lists.gnu.org/r/diffutils-devel/2023-01/msg00015.html and the fact that OpenBSD already has this option (as -b): https://man.openbsd.org/cksum Two questions: - blake2b's tag is inconsistently capitalized. All of the other tags are all-caps versions of their lower-case strings, but this one is spelled BLAKE2b, with a lower-case "b" at the end. I presume this is desired. Likely too late to change to make it consistent. Arose while considering how to implement support for the "x" and "b" option suffixes, to denote "use hex" or "use base64" as encoding, while the usual default is of course hex, and --base64 changes that. Leading to my second question: - I'm inclined to work like the openbsd cksum and accept invocations like "cksum -a sha1x" and "cksum -a sha1b". Any objection? Also, comparing algorithms, openbsd has two that we don't: rmd160, sha512/256 I'm not interested in adding those in this diff, of course, but it may be something to consider for compatibility. What's the schedule for the next release? Assuming this is desirable, want to include it there? My own ETA is variable, depending on pressure/desire. I've written most of the code (but not yet suffix support) and minimal tests, but no documentation or NEWS.
bug#61035: [PATCH] cp: improve help regarding ACLs
On Wednesday, January 25, 2023 11:01:45 PM CET Paul Eggert wrote: > On 2023-01-25 13:56, Ondrej Valousek wrote: > > But it's not the same meaning. What I am trying to explain here is that > > > > Cp -p (or cp --preserve=mode) also retains ACLs. This fact is not obvious, > > but yet it's happening > > Then I'm afraid I don't understand. In what sense do ACLs differ from > xattr here? As I understand it, `cp -p` now preserves ACLs but not xattr (unlike `cp -a`). Kamil
