#224 coreutils 5.2.1 sort can't open tmp file

[Anonymous]

I have sort.exe from coreutils 5.2.1, renamed as
gsort1.exe. When sorting files larger than the buffer
size, it has trouble finding its own temporary files.
Observe the problem here; I provide the previous
gnuwin32 gsort.exe for comparison. (I used cURL to get
a big file from iana.org; it isn't strictly necessary)

D:> gsort1 --version
sort (coreutils) 5.2.1
Written by Mike Haertel and Paul Eggert.

Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying
conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE.

D:> gsort --version
sort (textutils) 2.1
Written by Mike Haertel and Paul Eggert.

Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying
conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE.

D:> curl http://www.iana.org/assignments/enterprise-
numbers >blah
% Total % Received % Xferd Average Speed
Time Time Time Current
Dload Upload Total Spent
Left Speed
100 1729k 100 1729k 0 0 54902 0 0:00:32
0:00:32 --:--:-- 60099

D:> gsort -S128k blah >nul

D:> gsort1 -S128k blah >nul
gsort1: open failed: D:\DOCUME~1\Robert\LOCALS~1
\Temp/sortDg5ysG: No such file o
r directory

D:> dir D:\DOCUME~1\Robert\LOCALS~1\Temp\sort*
Volume in drive D has no label.
Volume Serial Number is 102B-9362

Directory of D:\DOCUME~1\Robert\LOCALS~1\Temp

File Not Found

D:> set tmp
TMP=D:\DOCUME~1\Robert\LOCALS~1\Temp
TMPDIR=D:\DOCUME~1\Robert\LOCALS~1\Temp

D:>

A fix is not a priority for me; since I have the older
version, I have a workaround in place. Just thought I'd
pass this along.

Thanks,
Robert Bassett
robert.bassett@datacore.com

[GnuWin]

Logged In: YES
user_id=217802

This bug report is accepted as valid and will be fixed in an
upcoming release.

[eliz]

Logged In: YES
user_id=1257325

I have seen similar problems
Using Process Explorer from PSTools, I found out that sort
creates a temporary file, uses it for a while, then deletes it, and
later tries to open it again and then fails. I also found that a few
seconds before it tries to open the deleted file, it opens another
temporary file, but then deletes it almost immediately.

I suspect that the logic that decides when to delete temporary
files somehow fails on Windows.

HTH

[GnuWin]

Logged In: YES
user_id=217802

This finding is correct: the mk(s)temp function was
implemented to open files with the O_TEMPORARY flag,
which deletes the file after it has been closed by the program.
This error has now been fixed, and the bug will disappear with
the next release of coreutils.

[GnuWin]

Logged In: YES
user_id=217802

This bug has been fixed. A new release is available through
http://gnuwin32.sourceforge.net/