bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#6657: mkstemp on cygwin creates binary files


From: Eric Blake
Subject: bug#6657: mkstemp on cygwin creates binary files
Date: Sat, 17 Jul 2010 17:54:25 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100621 Fedora/3.0.5-1.fc13 Lightning/1.0b2pre Mnenhy/0.8.3 Thunderbird/3.0.5

On 07/17/2010 12:13 AM, Paolo Bonzini wrote:
>> I don't see the problem with 'sort' offhand.  Why would the user care
>> whether
>> line endings in sort's temp files are \r\n or \n?  Using binary mode is a
>> bit faster and more reliable, surely.

Correct.  I see no reason to change sort.

>>
>> Or is there some problem if the file descriptor is created with O_BINARY
>> and then fdopen is called with "w" (and not "wb")?  I guess "sort" does
>> that on Cygwin now.
> 
> No idea.  I just thought a heads-up was in order...

fdopen(,"w") on cygwin honors the existing O_TEXT or O_BINARY flag of
the underlying fd; while only fdopen(,"wt") and fdopen(,"wb") force the
flag (and changes the flag of the underlying fd, if needed).

The problem with sed was that the temp file was then being rename()d
into the original file name, regardless of whether the final file should
be binary or text.  sort does not have the problem, because the
temporary file was truly temporary - it is not renamed into a
user-visible file after it is used.

By the way, newer cygwin provides mkostemp() - did you only fix the
problem for older cygwin that lacks mkostemp and thus gets the gnulib
fallback that doesn't force binary?  And what's wrong with using
setmode() (from <io.h>, or from gnulib's "binary-io.h") on the fd
created by mkstemp() to ensure the desired mode, rather than having to
use mkostemp?

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]