bug#12339: Bug: rm -fr . doesn't dir depth first deletion yet it is documented to do so.

Jim Meyering wrote: Thanks for the patch, but it would be pretty rotten for GNU rm to make it so "rm -rf ." deletes everything under ".", while all other vendor rm programs diagnose the POSIX-mandated error. People would curse us for making GNU rm remove their precious files when they accident

bug#12339: Bug: rm -fr . doesn't dir depth first deletion yet it is documented to do so.

On September 6, 2012 at 12:56 PM Linda Walsh wrote: > Jim Meyering wrote: > > Thanks for the patch, but it would be pretty rotten for GNU rm to make > > it so "rm -rf ." deletes everything under ".", while all other vendor > > rm programs diagnose the POSIX-mandated error. People would curse

bug#12339: Bug: rm -fr . doesn't dir depth first deletion yet it is documented to do so.

Linda Walsh wrote: ... > GNU needs to be clear their priorities -- maintaining software > freedom, or bowing down to corporate powers... POSIX isn't While POSIX is in general a very good baseline, no one here conforms blindly. If POSIX is wrong, we'll lobby to change it, or, when that fails, may

bug#12365: Incorrect return value of cp with no-clobber option

When -n (--no-clobber) option of cp is used and the DEST file exists, then, as expected, cp is not able to copy the SOURCE to DEST. However, cp returns 0 in this case. Shouldn't it return 1 to indicate that copy operation could not be completed? In absence of this indication how is one to know t

bug#12366: [gnu-prog-discuss] Writing unwritable files

[For bug-coreutils: the context here is that sed -i, just like perl -i, breaks hard links and thus destroys the content of files with 0400 permission]. Il 06/09/2012 12:38, John Darrington ha scritto: > That's expected of programs that break hard links. > > I wonder how many users who are no

bug#12366: [gnu-prog-discuss] Writing unwritable files

On 09/06/2012 01:12 PM, Paolo Bonzini wrote: [For bug-coreutils: the context here is that sed -i, just like perl -i, breaks hard links and thus destroys the content of files with 0400 permission]. Il 06/09/2012 12:38, John Darrington ha scritto: That's expected of programs that break hard

bug#12366: [gnu-prog-discuss] Writing unwritable files

Il 06/09/2012 14:30, Pádraig Brady ha scritto: >> >> I consider "shuf foo -o foo" (on a read-write file) to be insecure. >> Besides, it works by chance just because it reads everything in memory >> first. If it used mmap to process the input file, "shuf foo -o foo" >> would be broken, and the only

bug#12366: [gnu-prog-discuss] Writing unwritable files

On September 6, 2012 at 2:12 PM Paolo Bonzini wrote: > [For bug-coreutils: the context here is that sed -i, just like perl -i, > breaks hard links and thus destroys the content of files with 0400 > permission]. I consider this being 2 different cases: * 'sed -i' breaks hard links: That's bec

bug#12366: [gnu-prog-discuss] Writing unwritable files

Paolo Bonzini wrote: > [For bug-coreutils: the context here is that sed -i, just like perl -i, > breaks hard links and thus destroys the content of files with 0400 > permission]. Did I misunderstand how "destroy" is used above? $ echo important > k $ chmod a-w k $ sed -i s/./X/ k

bug#12366: [gnu-prog-discuss] Writing unwritable files

Il 06/09/2012 18:11, Paul Eggert ha scritto: >> > I consider "shuf foo -o foo" (on a read-write file) to be insecure. >> > Besides, it works by chance > It's not by chance. shuf is designed to let you > shuffle a file in-place, and is documented to work, > by analogy with "sort -o foo foo". If we

bug#12366: [gnu-prog-discuss] Writing unwritable files

On 09/06/2012 09:24 AM, Paolo Bonzini wrote: > A program that reads the target file will never > be able to observe an intermediate result. Sure, but that doesn't fix the race condition I mentioned. If some other process is writing F while I run 'sed -i F', F is not replaced atomically. That's t

bug#12366: [gnu-prog-discuss] Writing unwritable files

Il 06/09/2012 18:35, Paul Eggert ha scritto: >> > A program that reads the target file will never >> > be able to observe an intermediate result. > Sure, but that doesn't fix the race condition I > mentioned. If some other process is writing F > while I run 'sed -i F', F is not replaced atomicall

bug#12339: Bug: rm -fr . doesn't dir depth first deletion yet it is documented to do so.

Jim Meyering wrote: > Linda Walsh wrote: > ... > > GNU needs to be clear their priorities -- maintaining software > > freedom, or bowing down to corporate powers... POSIX isn't > > While POSIX is in general a very good baseline, no one here conforms > blindly. If POSIX is wrong, we'll lobby to c

bug#12365: Should cp -n return 0, when DEST exists?

On September 6, 2012 at 5:24 PM Jim Meyering wrote: > Bernhard Voelker wrote: > > Maybe it's worth adding a line about the exist status > > when using -n or -i (together with answering 'n')? > > Yes, please. That would be an improvement. (my first patch created on cygwin) >From 65d2d16340cee3

bug#12366: [gnu-prog-discuss] Writing unwritable files

Paul Eggert wrote: > >> If some other process is writing F > >> while I run 'sed -i F', F is not replaced atomically. > > > How not so? > > For example: > > echo ac >f > sed -i 's/a/b/' f & > sed -i 's/c/d/' f > wait > cat f > > If 'sed' were truly atomic, then the output of this would > always

bug#12366: [gnu-prog-discuss] Writing unwritable files

On 09/06/2012 10:12 AM, Bob Proulx wrote: > The file replacement is atomic. The reading of the file is not. Sure, but the point is that from the end user's point of view, 'sed -i' is not atomic, and can't be expected to be atomic. 'sed -i' and 'sort -o' both use some atomic operations internally

bug#12366: [gnu-prog-discuss] Writing unwritable files

On September 6, 2012 at 7:23 PM Paul Eggert wrote: > On 09/06/2012 10:12 AM, Bob Proulx wrote: > > The file replacement is atomic. The reading of the file is not. > > Sure, but the point is that from the end user's > point of view, 'sed -i' is not atomic, and can't > be expected to be atomic. >

bug#12339: Bug: rm -fr . doesn't dir depth first deletion yet it is documented to do so.

Bernhard Voelker wrote: On September 6, 2012 at 12:56 PM Linda Walsh wrote: Jim Meyering wrote: Thanks for the patch, but it would be pretty rotten for GNU rm to make it so "rm -rf ." deletes everything under ".", while all other vendor rm programs diagnose the POSIX-mandated error. Peop

bug#12350: Composites identified as primes in factor.c (when HAVE_GMP)

I and Niels now would appreciate feedback on the new factor code. We've put the entire little project in a tar file, which is attached. The code is also available at . Here is the README file: NT factor (Niels' and Torbjörn's factor, or New Technology factor)

bug#12350: Composites identified as primes in factor.c (when HAVE_GMP)

I and Niels now would appreciate feedback on the new factor code. We've put the entire little project in a tar file, which is attached. The code is also available at . Here is the README file: NT factor (Niels' and Torbjörn's factor, or New Technology factor)

bug#12366: [gnu-prog-discuss] bug#12366: Writing unwritable files

On Thu, 6 Sep 2012, Paolo Bonzini wrote: I'm not sure what is meant by "insecure" here. Of course there are race conditions if other processes modify a file when "shuf" reads or writes it, but that's true for pretty much any program that reads or writes any file, including sed -i. No, unlink/

bug#12366: [gnu-prog-discuss] Writing unwritable files

On 09/06/2012 10:35 AM, Bernhard Voelker wrote: > Why can't 'sed -i' be made atomic for the user? > Today, it creates a temporary file for the output. > At the end, it calls rename(). What if it instead > rewinds the input and that temporary file and copies > it's content to the input file? That's

bug#12366: [gnu-prog-discuss] bug#12366: Writing unwritable files

On Thu, Sep 06, 2012 at 11:23:21AM -0700, Paul Eggert wrote: On 09/06/2012 10:35 AM, Bernhard Voelker wrote: > Why can't 'sed -i' be made atomic for the user? > Today, it creates a temporary file for the output. > At the end, it calls rename(). What if it instead > rewinds

bug#12350: Composites identified as primes in factor.c (when HAVE_GMP)

Torbjorn Granlund wrote: > I and Niels now would appreciate feedback on the new factor code. > > We've put the entire little project in a tar file, which is attached. > The code is also available at . Thanks a lot! I've started looking at the code. I was surpris

bug#12350: Composites identified as primes in factor.c (when HAVE_GMP)

Jim Meyering writes: zsh: abort (core dumped) ./factor < k That was due to unexpected input. The parsing of the new factor is probably not too bad, but the error reporting could be better. :o) --- a/ourseq.c +++ b/ourseq.c @@ -48,7 +48,7 @@ incr (string *st) }

bug#12366: [gnu-prog-discuss] bug#12366: Writing unwritable files

Il 06/09/2012 20:21, Bob Friesenhahn ha scritto: >> >> No, unlink/rename "sed -i" replaces the file atomically. A program that > > POSIX rename assures that the destination path always exists if it > already existed. My bad, I meant link-breaking/rename. Of course you must not unlink first. Pa

bug#12350: Composites identified as primes in factor.c (when HAVE_GMP)

Torbjorn Granlund wrote: > I and Niels now would appreciate feedback on the new factor code. ... > * Our packaging with separate Makefile, outseq.c and ChangeLog was > useful during our development. We don't expect these to be useful > in coreutils. In particular, the slow testing of the 'che

bug#12350: Composites identified as primes in factor.c (when HAVE_GMP)

Jim Meyering writes: The existing code can factor arbitrarily large numbers quickly, as long as they have no large prime factors. We should retain that capability. OK, so we'll put the GMP demos program into this one. This opens another technical concern: We have moved towards proving p

bug#12350: Composites identified as primes in factor.c (when HAVE_GMP)

On 09/06/2012 02:33 PM, Jim Meyering wrote: >> > * We have some hardwired W_TYPE_SIZE settings for the code interfacing >> > to longlong.h. It is now 64 bits. It will break on systems where >> > uintmax_t is not a 64-bit type. Please see the beginning of >> > factor.c. > I wonder how many

bug#12350: Composites identified as primes in factor.c (when HAVE_GMP)

Jim Meyering wrote: > Jim Meyering wrote: > >> Torbjorn Granlund wrote: >>> The very old factoring code cut from an now obsolete version GMP does >>> not pass proper arguments to the mpz_probab_prime_p function. It ask >>> for 3 Miller-Rabin tests only, which is not sufficient. >> >> Hi Torbjorn >

bug#12365: closed (Re: Should cp -n return 0, when DEST exists?)

On Thu, Sep 6, 2012 at 8:03 PM, GNU bug Tracking System wrote: > Your bug report > > #12365: Incorrect return value of cp with no-clobber option > > which was filed against the coreutils package, has been closed. > > The explanation is attached below, along with your original report. > If you requ