GNU bug report logs -
#22769
In-place sorting of a file
Previous Next
Reported by: Yanyan Jiang <jiangyy <at> outlook.com>
Date: Mon, 22 Feb 2016 16:02:02 UTC
Severity: normal
Done: Paul Eggert <eggert <at> cs.ucla.edu>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 22769 in the body.
You can then email your comments to 22769 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-coreutils <at> gnu.org
:
bug#22769
; Package
coreutils
.
(Mon, 22 Feb 2016 16:02:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Yanyan Jiang <jiangyy <at> outlook.com>
:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org
.
(Mon, 22 Feb 2016 16:02:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
I found someone talking about sorting a file in-place:
http://stackoverflow.com/questions/9117274/do-i-need-to-generate-a-second-file-to-sort-a-file <http://stackoverflow.com/questions/9117274/do-i-need-to-generate-a-second-file-to-sort-a-file>
However, sort file.txt -o file.txt is NOT safe. A strace sequence (sorting 1 2 3 4 5):
read(3, "1\n2\n3\n4\n5\n\n", 4096) = 11
read(3, "", 4096) = 0
_llseek(3, 0, [11], SEEK_CUR) = 0
close(3) = 0
munmap(0xb7743000, 4096) = 0
ftruncate64(1, 0) = 0 <---------------------- (*)
fstat64(1, {st_mode=S_IFREG|0664, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7743000
write(1, "\n1\n2\n3\n4\n5\n", 11) = 11
close(1) = 0
If at this time, the system crashes (or later at write), the data is gone forever (or have a suffering recovery). Should we warn users of this, or add special treatment with this case (write a temp file and rename it)?
Thank your for your attention.
Regards,
Yanyan Jiang 蒋炎岩
Institute of Computer Software,
Dept. of Computer Science, Nanjing University
[Message part 2 (text/html, inline)]
Reply sent
to
Paul Eggert <eggert <at> cs.ucla.edu>
:
You have taken responsibility.
(Tue, 23 Feb 2016 07:54:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Yanyan Jiang <jiangyy <at> outlook.com>
:
bug acknowledged by developer.
(Tue, 23 Feb 2016 07:54:02 GMT)
Full text and
rfc822 format available.
Message #10 received at 22769-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Yanyan Jiang wrote:
> If at this time, the system crashes (or later at write), the data is gone forever (or have a suffering recovery). Should we warn users of this, or add special treatment with this case (write a temp file and rename it)?
Thanks for reporting the issue. Writing to a temp file and renaming would have
problems, as it might change the file's ownership or permissions or etc., and
also won't behave as the user expects if the file has multiple hard links. We
should at least warn users about the problem in the documentation, though, so I
installed the attached patch on Savannah at:
http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=4c1995f1b673b0e1eae73a9db4e28016b86dee9e
[0001-doc-document-sort-o-F-F-danger.txt (text/plain, attachment)]
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Tue, 22 Mar 2016 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 9 years and 97 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.