[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 not
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
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 way to fix
On September 6, 2012 at 2:12 PM Paolo Bonzini bonz...@gnu.org 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
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
$ cat
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 ever
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
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 atomically.
How
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 be 'bd'. But it's
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
On September 6, 2012 at 7:23 PM Paul Eggert egg...@cs.ucla.edu 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
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
12 matches
Mail list logo
