Hi,
First of all, small bug with getopt setup:
[EMAIL PROTECTED] ~]$ nice -n10 -p 10577
-n10: invalid option -- p
Try `nice --help' for more information.
[EMAIL PROTECTED] ~]$ nice -n +10 -p 10577
+10: invalid option -- p
Try `nice --help' for more information.
Next, a feature request: nice
Yesterday I reported that chown fails to ignore symbolic links during
recursive directory traversals.
...
I have filed a bug about this with Suse, but I'm posting this update
here as well since this issue means that running chown can have very
serious unintended consequences.
In case
Mark Brand [EMAIL PROTECTED] writes:
The problem had nothing to do with '-h'.
It has.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for
Mark Brand [EMAIL PROTECTED] writes:
In case anybody was following this issuse (original subject line chown
fails to ignore symbolic links during recursive directory
transversals[sic]), SuSE has released a fix for their coreutils RPM:
Has this problem (whatever it is) been fixed in coreutils
The problem had nothing to do with '-h'.
It has.
Andreas.
The info included with the patch seemed to imply that you would have to
use the -h option to experience the problem, which is not the case.
Perhaps your point is that the problem was caused by something in the
code related to
In a few obscure instances mkdir, mkfifo, and mknod create files with
incorrect permissions. For example:
$ umask 027
$ mkdir -m =+x a
$ ls -ld a
d--x--x--x 2 eggert eggert 4096 Apr 22 17:03 a
The permissions are wrong here. They should be d--x--x---.
I verified that Solaris 8
Mark Brand [EMAIL PROTECTED] writes:
The problem had nothing to do with '-h'.
It has.
Andreas.
The info included with the patch seemed to imply that you would have to
use the -h option to experience the problem, which is not the case.
Perhaps your point is that the problem was
