bug#8527: cp/mv in coreutils don't respect the default ACL of parent
f0r...@free.fr wrote: 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. What file system and core utils are you using? 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? 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 /Media/Library/_artwork/test/ Ishtar:/tmp lsacl /Media/Library/_artwork/test [u::rwx,u:Media:rwx,g::rwx,g:Media:rwx,m::rwx,o::r-x/u::rwx,u:Media:rwx,g::rwx,g:Media:rwx,m::rwx,o::r-x] /Media/Library/_artwork/test (note, 2nd acl is default dir (lsacl uses chacl -l) Ishtar:/tmp 'cp' -r /Media/Library/_artwork/test . #recursive to tmp Ishtar:/tmp llg -d test drwxrwxr-x 2 law lawgroup 6 Oct 7 02:34 test/ Ishtar:/tmp lsacl test #no attr indicated [u::rwx,g::rwx,o::r-x] test #default ACL shown So far all seems fine. 4) Now lets copy the perms too: Ishtar:/tmp rd test Ishtar:/tmp 'cp' -a /Media/Library/_artwork/test . Ishtar:/tmp llg -d test drwxrwsr-x+ 2 law Media 6 Oct 7 02:33 test/ Ishtar:/tmp lsacl test #same ACL as source [u::rwx,u:Media:rwx,g::rwx,g:Media:rwx,m::rwx,o::r-x/u::rwx,u:Media:rwx,g::rwx,g:Media:rwx,m::rwx,o::r-x] test 5) create file in that dir: Ishtar:/tmp cd test Ishtar:/tmp/test touch touched_file Ishtar:/tmp/test llg touched_file -rw-rw-r--+ 1 law Media 0 Oct 7 02:42 touched_file Ishtar:/tmp/test lsacl touched_file [u::rw-,u:Media:rwx,g::rwx,g:Media:rwx,m::rw-,o::r--] touched_file --- File has expected inherited ACL. 6) Now ... lets use cp to copy a file w/o acls in: (first create normal file under /tmp): echo perm test/tmp/perm.txt Ishtar:/tmp/test llg /tmp/perm.txt -rw-rw-r-- 1 law lawgroup 10 Oct 7 02:59 /tmp/perm.txt Ishtar:/tmp/test lsacl /tmp/perm.txt [u::rw-,g::rw-,o::r--] /tmp/perm.txt 'cp' /tmp/perm.txt . Ishtar:/tmp/test llg perm.txt -rw-rw-r--+ 1 law Media 10 Oct 7 03:01 perm.txt Ishtar:/tmp/test lsacl perm.txt [u::rw-,u:Media:rwx,g::rwx,g:Media:rwx,m::rw-,o::r--] perm.txt 8) Looks the same to me...However, check this out: Ishtar:/tmp/test rm perm.txt Ishtar:/tmp/test cp /tmp/perm.txt . Ishtar:/tmp/test llg /tmp/perm.txt -rw-rw-r-- 1 law lawgroup 10 Oct 7 02:59 /tmp/perm.txt Ishtar:/tmp/test lsacl perm.txt No acl this time, but same copy...or was it? Note I was careful to use 'cp' most of the time when copying except this last time, cuz: alias cp alias cp='cp --preserve=mode,timestamps' my normal cp is an alias -- that says to preserve the mode. It wouldn't be able to do that if it allowed the default ACL to be set on the file. -- So, I don't know if this is related to your problem, but cp appears to be working correctly here filesystem = xfs (acls are always on as they came with the filesystem). kernel= Linux Ishtar 3.16.2-Isht-Van #1 SMP PREEMPT Tue Sep 9 18:26:43 PDT 2014 x86_64 x86_64 x86_64 GNU/Linux == If this was any help -- great, if it was an annoyance, just delete it and I can claim my dog ate my keyboard... (funny things come out of dogs stomachs ;-))...
bug#18491: rm -r fails to delete entire hierarchy when path goes in and out of it
Bob Proulx wrote:
Gian Ntzik wrote:
It seems that using rm -r with a path that goes into a (non-empty)
directory intended for removal (and back up e.g. using dot-dots) fails
to remove the directory. The directory is rendered empty, but itself not
removed.
For example,
$ mkdir -p /tmp/a/b/c
$ mkdir -p /tmp/a/e
$ rm -r /tmp/a/b/../../a
rm: cannot remove ‘/tmp/a/b/../../a’: No such file or directory
I don't think this can reasonably be called a bug. A depth first
removal is required.
I would tend to agree, but if you try to remove /tmp/a/.
a depth first removal won't be tried -- so it is obviously not required.
Trying to do anything to work around this seems wrong to me since it
will require keeping track of the state before and simulating to
create the desired state afterward and then applying a derived state
change to the file system. That is much too complex for this simple
operation.
One would think the same for rm -fr foo/., but the
straight-forward application of the depth-first removal was
removed from rm for special cases. One would think
that the underlying tree might be easily addressed:
function rmr {
local rd=$(cd $1; /bin/pwd)
echo rm -r $rd
}
same dir struct as above:
tree /tmp/a
/tmp/a
├── b
│ └── c
└── e
rmr /tmp/a
rm -r /tmp/a
---
If rm should delete the directory and its contents as it is documented
to do except where POSIX prohibits it, (like rm -fr dir/.),
then except for POSIX instructions to the contrary, it seems it
should make at least as trivial an effort as the above. :-|
bug#14525: ls -k produced no size, ls -lk lists in bytes? What's up w/k?
Pádraig Brady wrote: On 06/01/2013 02:02 AM, Linda Walsh wrote: in Coreutils 8.21.1.1 (x86_64) on snoozy When I type in ls -k, I get a small listing (filenames only horizontally) (and no sizes). When I type in ls -lk, I get a long listing -- but it isn't using K, but bytes. Since coreutils 8.15 the behavior was changed to be more consistent with other systems and POSIX: http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commit;h=448718 What replaced it? I mean it doesn't do something *different*, it just ignores it. So does this mean that to be POSIX compatible all the utils will have to be dumbed down and have functionality removed? If you needed it for something else, or something else replaced it -- that's one thing, but it seems like the trend is just removing added functionality that gnu-linux users have come to enjoy... Do we need a new non-posix core utils that keeps the extended functionality? I don't understand why you guys are butchering the gnu products and removing features to comply with posix... it was never intended to be a highest common denominator, but a lowest...
bug#12339: [PATCH] rm: avoid bogus diagnostic for a slash-decorated symlink-to-dir
Paul Eggert wrote: On 09/04/2012 11:58 PM, Linda A. Walsh wrote: I'm not talking for interactive use... I'm talking for use in a script that might run on systems that are not mine -- so I can't rely on shell settings. Yes you can. Just start the script with #!/bin/sh, as usual. When invoked that way, Bash and other shells are POSIX-compliant in this area. To what level of posix... if they are compliant to the original level then they might have the original behavior that allowed rm -r . to work. if they are the 2003 version, then a different way, .. bleh. I overly worry about things that don't occur, but get caught by things I didn't worry enough about. So it doesn't really matter. I just preferred simplicity to the ever changing posix.
bug#12339: [PATCH] rm: avoid bogus diagnostic for a slash-decorated symlink-to-dir
Jim Meyering wrote: These commands would evoke an invalid diagnostic: $ mkdir d ln -s d s env rm -r s/ rm: cannot remove 's': Too many levels of symbolic links remove.c was stripping trailing slashes from s/ before passing the name to rm. But a trailing slash may change the semantics, and thus should not be stripped. I would assert that the trailing . shouldn't be stripped either. If the directory is a mount point -- then . would indicate the contents of the mount point -- being after the /, while the / would be the mount point itself. In my case, I wanted to delete everything in the mount point. Removal of the mount point itself would ideally unmount the 'fs', but I won't hold my breath on that one (and leave the root inode of the file system in the unmounted file system -- thus I've effectively removed . from mountpoint/. Which is different from the . of a directory entry -- NO I'm not asking for this as a feature, I'm just saying it would be a valid semantic paradigm). I WOULD want rm dir foobar/. to remove all contents in the directory before failing on .. The original version of posix didn't have this restriction/problem. POSIX is portability standard -- it should not be regarded as a restrictive standard, unless not doing so would hinder portability. In effect, they are disallowing OS's to make extensions beyond what they allow in the newer standards... That goes WAY beyond a portability standard...
bug#12339: [PATCH] rm: avoid bogus diagnostic for a slash-decorated symlink-to-dir
Paul Eggert wrote: On 09/04/2012 10:46 AM, Linda A. Walsh wrote: I would assert that the trailing . shouldn't be stripped either. If we were designing anew, I'd be inclined to agree with you. But there are probably people expecting the standard behavior now, i.e. expecting it to do nothing useful other than issue an error? Who would type that in, expecting that? What useful purpose does it serve? and there's an argument for not departing from the standard unless there's a good reason. Usability, Expressiveness. Here, if we can provide a command rm -fr foo/ to do what you want, then I hope it's merely a minor glitch that rm -fr foo/. Ok, will foo/ remove the contents only and not the directory? If so, then it's a replacement -- that sounds like what is being talked about .. yes? It seems so fragile -- because some utils require the /. to make sure you don't ALSO remove the directory. if I remove foo/. I know, unambigously, that the directory foo won't be removed. With foo/, it will depend on the program. That means other programs will have to change to be compat with the new standard -- when they were all compat before when foo/. did a recursive remove and gave an error at the end about can't remove . That was a behavior I've relied on...(i.e. if it really did remove ., that would defeat the purpose of the of the safety invocation. However, adding foo/ -- does that imply that ./ will also work? so now rm -fr ./ will work? That's awfully close to rm -fr /. just as rm -fr ./* is close to rm -fr /.* I've never relied on rm to protect me from rm -fr /, which is why I have tended to use relative paths with . and ending in . if I wanted to keep the dir, or not -- as there is ALOT of code out there that removes trailing slashes... (like the code under discussion -- perfect example)it is by far not the only one to treat '/' as option at the end of a path.
bug#12339: [PATCH] rm: avoid bogus diagnostic for a slash-decorated symlink-to-dir
Paul Eggert wrote: On 09/04/2012 04:21 PM, Linda A. Walsh wrote: Paul Eggert wrote: expecting it to do nothing useful other than issue an error? Sure. People might expect the utility to complain about what they consider to be obvious typos, rather than to remove files they don't expect to be removed. For example: rm -fr .* safely removes all file names beginning with . in the working directory, without inadvertently removing file names that do not begin with ., or files in the parent directory. I can see people being used to this sort of thing, and being annoyed greatly if we change it. i wouldn't regard that as safe. I always use rm -fr .[^.]* Why is that interfaces must sync to the lowest level. unix was NOT supposed to be that way. Ok, will foo/ remove the contents only and not the directory? No, rm -fr foo/ removes the directory too. So how do delete all files in the directory without wild cards? (as you don't know how or if they will be expanded). (only VERY recently has bash included . in * -- it used to be ignored and still is if you have flags set to ignore it. Shells don't consistently expand wildcards, and the OS doesn't expand them at all (i.e. when passed in 'exec')... This is what I mean about useful features being removed in order to dumb down the interface -- as dir/ also tries to remove the dir... which isn't likely to work on a mount point.
bug#11621: questionable locale sorting order (especially as related to char ranges in REs)
Pádraig Brady wrote:
On 06/04/2012 06:03 AM, Linda A. Walsh wrote:
Pádraig Brady wrote:
On 06/03/2012 11:13 PM, Linda Walsh wrote:
Within in the past few years, use of ranges in RE's has become
unreliable due to some locale changes sorting their native character
sets such that aAbByYzZ (vs. 'C' ordering ABYZabyz).
There seems to be a problem in when a user has set their system to use
Unicode, it is no longer using the locale specific character set (iso-8859-x,
or others).
To clarify my above statement:
There seems to be a problem in when a user has set their system to use
Unicode: It is no longer using the locale specific character set (iso-8859-x,
or others) -- ***or*** *their* *orderings*. I.e. Unicode defines a collation
order -- I don't know that they others do ('C' does, but I don't know about
other locale-specific character sets).
It's not specific to unicode. Sorting in a iso-8859-1 charset
results in locale ordering:
Can you cite a source specifying the sort/collation order of the
iso-8859-1 charset that would prove that it is not-conforming to the collation
specification for that charset?
I.e. If there is no official source, then the order with that charset
is undefined, and while it may not be desirable, returning aAbB, would not be
an error.
It's a charset. Of course the order is defined. Try: man iso-8859-1
The relative ordering can be trivially inferred from the command I presented.
But to be explicit:
$ printf %s\n A b a á | iconv -t iso-8859-1 | LC_ALL=en_US [sic] sort | iconv
-f iso-8859-1
a
A
á
b
Your example doesn't show the collation order of iso-8859-1. You are
setting it to 'en_US' (as LC_ALL overrides all other LC vars; LANG sets
the default, but individual settings in the LC variables can override it.
A corrected example:
$ (Charset=iso-8859-1; printf %s\n A b B a á | iconv -t $Charset |
LANG=en_US LC_CHARSET=$Charset LC_COLLATE=$Charset sort | iconv -f
$Charset |tr \n ;echo )
A B a b á
(I used 'Charset' to hold the charset name, added parens, printed them
in the same orientation as input, and added a 2nd capital letter to make
upper/lower case ordering clear.)
I might note how trivial it was to arrive at incorrect output.
People often think me a pain because I ask them to explain what they
perceive to be
obvious. Unfortunately, what is obvious to 1 person may not be so to
another.
The 'á' is not ASCII (original charset for C locale, coming from
unix C programming language -- a reason why POSIX renamed the 'C'
local to the POSIX
locale.
However, as 'á' is in the 1st 256 chars (above the ASCII range), it
can still work if you remove the iconv stuff (and note, I have no other
locale vars
set:
$ echo ${!LC_*} ${!LAN*}
LC_COLLATE LC_CTYPE
$ (Charset=ASCII; printf %s\n A B b a á | LC_CHARSET=$Charset
LC_COLLATE=$Charset sort |tr \n ;echo )
A B a b á
To bring this to completion -- most linux systems today use the UTF-8
character set. It shows an *identical* collation order for the above
chars as the iso-8859-1 charset.
It appears that the collating functions are confused by the notation
that has been adopted in many distributions...namely locale.charset.
In such a notation, where the charset has been explicitly specified, and
where the charset has explicit COLLATION and case folding rules (those
for Unicode are extensive and handle accents as well as other forms like
ſȘșʂȿᵴᶊṠṡṢṣṤṥṦṧṨṩẛẜẝẞⱾꞨꞩSsߌśŜŝŞşŠšˢ...etc.
Therefore, I would like to see the character set's collation and
folding rules used where they are officially specified (as in the case
of Unicode or POSIX).
Are you the person responsible for the libicuXXX files?
bug#11621: questionable locale sorting order (especially as related to char ranges in REs)
Pádraig Brady wrote:
On 06/03/2012 11:13 PM, Linda Walsh wrote:
Within in the past few years, use of ranges in RE's has become
unreliable due to some locale changes sorting their native character
sets such that aAbByYzZ (vs. 'C' ordering ABYZabyz).
There seems to be a problem in when a user has set their system to use
Unicode, it is no longer using the locale specific character set (iso-8859-x,
or others).
To clarify my above statement:
There seems to be a problem in when a user has set their system to use
Unicode: It is no longer using the locale specific character set (iso-8859-x,
or others) -- ***or*** *their* *orderings*. I.e. Unicode defines a collation
order -- I don't know that they others do ('C' does, but I don't know about
other locale-specific character sets).
It's not specific to unicode. Sorting in a iso-8859-1 charset
results in locale ordering:
Can you cite a source specifying the sort/collation order of the
iso-8859-1 charset that would prove that it is not-conforming to the collation
specification for that charset?
I.e. If there is no official source, then the order with that charset
is undefined, and while it may not be desirable, returning aAbB, would not
be an error.
http://unicode.org/charts/case/chart_Latin.htm.
http://unicode.org/charts/case/chart_Latin.html
---
^^Correct^^ (typho)
Temporarily ignoring accents, only talking about lower and upper
case letters, ...
Well case comparison is a complicated area.
A bit, but it's mostly just wrong in the gnu library concerning
unicode, and,
as you are pointing out -- the 'C' encoding as well.
the 'C' locale was the original charset used by the 'C' language -- only 8 bits
wide.
So how can it sort characters beyond the lower 256?
This would seem to be meaningless and bugs output.
Is it?... When the case comparison ordering is specified in a
standard, it makes it fairly clear that one is either compliant with the
standard
or not.
In this case, the Gnu sort/collation lib is not Unicode/UTF-8 compliant.
What happens in other charsets may or may not be covered under some
other standard -- e.g. the 'C'/ascii ordering is specified. But I don't know
if others have relevant standards or not.
For the special case of discounting accented chars etc.
you can use an attribute of the well designed UTF-8.
---
This is not exactly the point -- the point is that the core sort
DOESN'T use that ordering. That's the bug I am reporting.
In reporting this, I'm trying to keep the argument 'simple' and focus on
the problem of widely used ranges in the first 256 code-points of
Unicode.
Unicode gives a fairly extensive algorithm for handling accents,
but I didn't want to complicate the discussion by going there. Please
focus this bug on the lower 128 code points, as full unicode compliance
with the full collation algorithm that is specified is likely to be a
larger task. HOWEVER, fixing the sorting/collation order of the lower
127 code points, is, comparatively a small task that conceivably could be
fixed in the next release.
Enabling traditional byte comparison on (normalized) UTF-8 data
will result in data sorted in Unicode code point order:
A b a á = A a b á
But you are missing the point (as well as raising an interesting
'feature'(?bug?)).
How is it that 'C' collation collates characters that are outside the ascii
range?
I.e. -- you can't interpret input data as 'unicode' in the 'C' locale.
So how does this work in the 'C' local? AND more importantly -- it SHOULD work
when charset is unicode (UTF-8)... and does not. Test prog:
---
#!/bin/bash
set -m
# vals to test:
declare -a vals=( A a B b X x Y y Z z Ⅷ Ⅴ Ⅲ Ⅰ Ⅿ Ⅽ ⅶ ⅼ ⅲ )
COLLATE_ORDER=C
function isatty {
local fd=${1:-1} ;
0$fd tty -s
}
function ord {
local nl=;
isatty nl=\n
printf %d$nl '$1
}
function background_print {
readarray -t inp
for ch in ${inp[@]}; {
printf %s (U+%x)\n $ch $(ord $ch)
}
}
printf %s\n ${vals[@]} |
LC_COLLATE=$COLLATE_ORDER sort |
background_print
Note, that the above produces:
/tmp/stest
Ⅷ (U+2167)
Ⅴ (U+2164)
Ⅲ (U+2162)
Ⅰ (U+2160)
Ⅿ (U+216f)
Ⅽ (U+216d)
ⅶ (U+2176)
ⅼ (U+217c)
ⅲ (U+2172)
a (U+61)
A (U+41)
b (U+62)
B (U+42)
x (U+78)
X (U+58)
y (U+79)
Y (U+59)
z (U+7a)
Z (U+5a)
NOT the output you showed...Seems there's a bug in the C collation order?
Changing collation order to UTF-8:
Same thing:
/tmp/stest
Ⅷ (U+2167)
Ⅴ (U+2164)
Ⅲ (U+2162)
Ⅰ (U+2160)
Ⅿ (U+216f)
Ⅽ (U+216d)
ⅶ (U+2176)
ⅼ (U+217c)
ⅲ (U+2172)
a (U+61)
A (U+41)
b (U+62)
B (U+42)
x (U+78)
X (U+58)
y (U+79)
Y (U+59)
z (U+7a)
Z (U+5a)
I would assert this is a serious bug that should be addressed ASAP...
As for the question
bug#10055: [sr #107875] BUG cp -u corrupts 'fs'' information if interupted; can't recover on future invoctions
Jim Meyering wrote: Linda A. Walsh wrote: Hmmm Dang strange processes on bugs... can't submit directly bug can just by emailing it to the email list? ... (bureaucracy!) Linda Walsh wrote: This should be filed under bugs, not under support, but it seems that users of the core utilis are ot allowed to find bugs...convenient. Thanks for the report. Please do not use savannah's bug or support interfaces for coreutils. We deliberately disabled the former. Now, when you send a message to the bug-coreutils mailing list, it creates a ticket for you. Yours is here: [1]http://bugs.gnu.org/10055 Simply replying to any mail about it adds entries to its log. But that's not the bug db interface...thats just a log...where? the bug db intface for the bug in the bug database? References 1. http://bugs.gnu.org/10055
bug#10055: [sr #107875] BUG cp -u corrupts 'fs'' information if interupted; can't recover on future invoctions
Paul Eggert wrote: A) catch INT ( catchable signals), and remove any files that are 'incomplete' That might cause trouble in other cases. For example, cp A B where B already exists. === Am **only** suggesting this where 'B' has already been opened and truncated by stuff being copied from 'A'... The point is to not leave a 'B' that is *indeterminate*. In this case it's unwise to remove B if interrupted -- people won't expect that. -- Better than leaving *doo doo* in a file where they expect some.thing valid. And in general 'cp' has behaved the way that it does for decades, and we need to be careful about changing its default behavior in such a fairly-drastic way. It's a bug...Fixing a bug isn't usually considered drastic. But we could add an option to 'cp' to have this behavior. Perhaps --remove-destination=signal? That is --remove-destination could have an optional list of names of places where the destination could be removed, where the default is not to remove it, and plain --remove-destination means --remove-destination=before. I think you misunderstood the problem.
bug#10055: [sr #107875] BUG cp -u corrupts 'fs'' information if interupted; can't recover on future invoctions
Hmmm Dang strange processes on bugs... can't submit directly bug can just by emailing it to the email list? ... (bureaucracy!) Linda Walsh wrote: This should be filed under bugs, not under support, but it seems that users of the core utilis are ot allowed to find bugs...convenient.
bug#10055: [sr #107875] BUG cp -u corrupts 'fs'' information if interupted; can't recover on future invoctions
Paul Eggert wrote: On 11/15/11 12:46, Linda A. Walsh wrote: Better than leaving *doo doo* in a file Sometimes, but not always. I can think of plausible cases where I'd rather have a partial copy than no copy at all. As an extreme example, if I'm doing 'cp /dev/tty A', I do not want A removed on interrupt even if A has already been truncated and overwritten, as A contains the only copy of the data that I just typed in by hand. But we could add an option to 'cp' to have this behavior. Perhaps --remove-destination=signal? That is --remove-destination could have an optional list of names of places where the destination could be removed, where the default is not to remove it, and plain --remove-destination means --remove-destination=before. I think you misunderstood the problem. Perhaps I did. But could you explain the problem then? For example, how would the proposed cp --remove-destination=signal A B not address the problem?
bug#10055: [sr #107875] BUG cp -u corrupts 'fs'' information if interupted; can't recover on future invoctions
[Thought I send out rspns to this, but can't find it in my outgo, so...recomposing/sending, sorry for delay) On 11/15/11 12:46, Linda A. Walsh wrote: Better than leaving *doo doo* in a file Sometimes, but not always. I can think of plausible cases where I'd rather have a partial copy than no copy at all. As an extreme example, if I'm doing 'cp /dev/tty A', I do not want A removed on interrupt even if A has already been truncated and overwritten, as A contains the only copy of the data that I just typed in by hand. = A A A Um...yeah, you could try to apply the idea in general, but it might not have unforeseen side effects like you are demonstrating.A A Why don't we focus on the specific problem mentioned which was using it in the context of the -u flag, (and with -a/-r and/or a wildcard), where you expect it to update contents of 'Dst' with 'Src'. In that case, you get interrupt, and you end up with a truncated file in Dst, that has some (not even the DT of the src file, but the DT the file was opened (or more likely closed) DateTime that will guarantee, that a correct copy will never get updated over the now, destroyed, bogus copy.A Not only that, but weeks later, when you go though your backup dir, and wonder why some file 'x' is only 1/10th the size of the rest of the similar backups, your original can be very gone...(not that 1 of the multiple other backups might not sub-in, but that's not the point!)...A You don't want the partially copied update -- that has already destroyed an original, to now leave a turd in place so that no future cp -uav will correct the problem Though, (I'm sure you'd love to see this in 'cp', (*cough*), cp could check file sizes and see if the target is smaller and if so.. assume, if the DT's were equal that the file cp was interrupted...and finish it... Actually that might not be a bad idea... But we could add an option to 'cp' to have this behavior. Perhaps --remove-destination=signal? That is --remove-destination could have an optional list of names of places where the destination could be removed, where the default is not to remove it, and plain --remove-destination means --remove-destination=before. I think you misunderstood the problem. Perhaps I did. But could you explain the problem then? For example, how would the proposed cp --remove-destination=signal A B not address the problem? Well, if it were the default case, sure, but if default is to trash files, that's bad.
bug#9987: RFE: 'groups' command ADD command switches -0, and -1
Pádraig Brady wrote: On 11/07/2011 10:27 PM, Linda Walsh wrote: I'd like to request an RFE for the groups command to add 2 switches: -1 - print groups in 1 column (cf. ls -1) -0 - print groups followed by null (cf. find et al) reasons: have groups with spaces in them. provide ultimate safety/futureproof with -0 ?? reasonable? Hmm. I suppose by extension that `id -Gn` should accept -1 too. But do you really want to support group names with spaces? `groupadd` for example won't allow this. I suppose integration with LDAP etc. might get arbitrary group names. I already have groups and usernames with spaces in them. Just try merging/supporting a Windows environment via linux. I EVEN have usernames with \ in them!... Was required for 'ssh' to work...since when I'm validated as 'user' via samba, when I 'ssh' in from a domain workstation, it comes in as user Domain\user. I just added an extra PW entry for Domain\me, same as me, and it works... Fortunately most core utils are mostly agnostic towards these things... it's when you get to talking to people who who tell you that spaces and backslashes don't belong there cuz God didn't intend it, that you get into 'religious' discussions' Anything other a a null (or colon) should be fair game for user/groupnames -- I'd feel uncomfortable about control chars, but hey. no reason *technically*, why they should be disallowed (policy is separate from technical implementation! ;-)). NT does Unix 1 better -- they alway use a count for strings. So even 'nulls' are ok... though windows, like linux uses null-terminated strings. This leads to interesting hacks in windows where NT-progs can create reg-entries and files that Windows progs can't touch/see due to embedded nulls. Might lead to some interesting file portability probs for NT files created with an NT inteface, say on an NTFS file system (dunno about FAT), that linux couldn't see -- might even be a way for NT to hide stuff from linux...especially since linux supports NTFS and FAT...probably not an issue in FAT. I'm unsure about NTFS though as it uses the same naming rules as the registry, I don't see why it wouldn't have the same gotcha's. I do know it's a prob in the registry...various vendors like to hide registration data with embedded nulls in them so they can't be touched by normal user processes (ms-sysinternals/regdelnull tool will wipe them...but not make them readable...would rather it change the nulls to spaces or such...)... Note POSIX is quite specific about the output format for `id`: --- Which posix? there are about 3-4 different versions. They are NOT compatible. I.e. a shell script written against the 1988 (1990?) spec won't necessarily work against the 2008 specetc. So you can put alot of stock in POSIX, but you better specify which POSIX you are talking about ... as for me, as soon as POSIX became incompatible with POSIX, i realized, that they'd lost the way ;-) −G Output all different group IDs (effective, real, and supplementary) only, using the format %u\n. If there is more than one distinct group affiliation, output each such affiliation, using the format %u, before the newline is output. Um... I don't think the same problem would exist in put out 'uid'/rid' which are 32-bit unsigned integers, vs. 'UTF-8 encoded strings' for user names.. Two different problem spaces... I mean you *could* add those options for numeric output, but, personally, I don't think that would be a logical step.
bug#9987: RFE: 'groups' command ADD command switches -0, and -1
Pádraig Brady wrote: Hmm. I suppose by extension that `id -Gn` should accept -1 too. But do you really want to support group names with spaces? `groupadd` for example won't allow this. I suppose integration with LDAP etc. might get arbitrary group names. ... i.e. some don't have names (thanks samba/winbind!)... Some map to BUILTIN\ Since I'm logged into the Domain Controller, I wouldn't expect to see the Domainname, FWIW, when I type in 'id', I get: id uid=5001(lindaw) gid=201(lwgroup) groups=201(lgroup),0(root),5(tty),6(disk),8(mail), 10(wheel),12(games),14(uucp),16(dialout),17(audio),18(SYSGROUP), 20(cdrom),30(wwwrun),31(squid),42(trusted),44(named),76(ldap),100(backup),132(spamd), 133(video),200(unix_users),202(home),203(private),204(powerd),212(mailadmin),213(devel), 215(lighttpd),225(yard),231(Juno),232(scan),237(cronusers),238(atusers),260(torrent), 512(Domain Admins),513(Domain Users),517(Cert Publishers), 518(Schema Admins),519(Enterprise Admins),544(Administrators), 545(Users),547(Power Users),548(Account Operators), 551(Backup Operators),555(Remote Desktop Users), 558(Performance Monitor Users), 5001(lindaw),10001,10002,10003,10004,10005,10006,10007, 10008,10010,10011,10012,10013,10014,10015,10016,10017,10018, 10019,10020,10021,10022,10023,10024,10025,10026,10027,10028, 10029,10030,10031,10032,10046,10051(BUILTIN\administrators), 10052(BUILTIN\users),10060,20001(media), 50001(samba),50002(Trusted Local Net Users), 50003(CPAN) But on my Windows 7 workstation, under cygwin, I type in 'id' and I see: uid=90026(Bliss\lindaw) gid=71008(Bliss\lwgroup) groups=71008(Bliss\lwgroup),0(root),544(Administrators), 555(Remote Desktop Users),545(Users),1005(lwgroup), 11023(Bliss\torrent),11017(Bliss\media), 60002(Bliss\Trusted Local Net Users), 10512(Bliss\Domain Admins),11039(Bliss\Unix Group root) (none of the local groups are mapped over, but some of the the groups are 'domain group' and get mapped over...)... See and there's that 'Bliss\lindaw', on cygwin, that I had to deal with on linux... Of course, another problem Samba causes is it mangles the case names, -- windows partly cares and linux/unix REALLY cares I've tried to get them to change that, but they pretty much threw up there hands and said 'too big a bug to fix...break it down into small pieces for us'... (since it involves user names, groupnames, domain names, hostnames, etc... Windows is case preserving but ignoring, vs. samba is case mangling (upper or lower depending on what it 'thinks' it is, which is great, since user and host names get mangled in opposite directions, but hostnames have to be registered as usernames ...Of course you have nimnils like me, who are silly enough to use 'Upper and Lower case...and boy ... it *USED* to work for years...but that was before ...about 6 months ago...I think they either changed something in samba, in windows or both... Have seen more than one notation on the internet about how MS has done things to break samba compatibility over the years...Now they are both allowing mixed case, and in some cases treating it differently... My workstation is listed as belonging to workgroup 'BLISS', but domain 'Bliss' (my domain name took it's name from the initial XP background (bliss.jpg/bliss.scr)...green grass blue sky...)...It was meant as 'irony..'Bliss... windows...'...oi! -- Using a somewhat reverse mode of attack,in the Music-labeling space, MS media player is refusing to play any songs labeled in UTF-8...has to be UTF-16 (which is also illegal, but gets by because it's too hard to tell from USC-2) which is what is allowed) So there they are shutting out products that don't conform to their standard (of course interestingly the id3v2.org folks are well padded with MS-centric standards and lingo... Gee..I wonder who sponsors them...
