emacs-bug-tracker
[Top][All Lists]
Advanced

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

[debbugs-tracker] bug#11816: closed (sort -o: error comes late if openin


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#11816: closed (sort -o: error comes late if opening the outfile fails)
Date: Mon, 02 Jul 2012 10:27:02 +0000

Your message dated Mon, 02 Jul 2012 12:21:38 +0200
with message-id <address@hidden>
and subject line Re: bug#11816: sort -o: error comes late if opening the 
outfile fails
has caused the debbugs.gnu.org bug report #11816,
regarding sort -o: error comes late if opening the outfile fails
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
11816: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11816
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: sort -o: error comes late if opening the outfile fails Date: Fri, 29 Jun 2012 13:54:32 +0200 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120601 Thunderbird/13.0
If opening the output file for writing is not possible - e.g. because the user
doesn't have sufficient privileges, then sort issues an error. The problem
is that the whole - then useless - computation is already done.

In the following little example, it took ~15s to sort the data,
and then to realize that it can't write the result:

  $ time seq 1000000 | src/sort --random-sort -o /cantwritehere
  src/sort: open failed: /cantwritehere: Permission denied

  real    0m14.955s
  user    0m14.936s
  sys     0m0.042s

I'd have expected sort to give the error immediately after startup
instead of wasting time for sorting.
Shouldn't sort open the outfile right at the beginning (unless in==out),
or is this behavior required by some standard?

Have a nice day,
Berny




--- End Message ---
--- Begin Message --- Subject: Re: bug#11816: sort -o: error comes late if opening the outfile fails Date: Mon, 02 Jul 2012 12:21:38 +0200 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0
On 06/30/2012 03:11 PM, Pádraig Brady wrote:
> On 06/30/2012 12:53 PM, Paul Eggert wrote:
>> On 06/29/2012 07:55 AM, Pádraig Brady wrote:
>>> Also the in==out case, you'd like to check for write-ability too.
>>>
>>> Both cases could be handled I think with something like:
>>>
>>> if (access (outfile, W_OK) != 0 && errno != ENOENT)
>>>   error (...);
>>
>> Wouldn't it be better to actually open the output file,
>> but not truncate it?  We can then truncate it just before
>> actually writing to the file.  That would avoid a race
>> condition or two.
>>
>> In the in==out case, we could tune this by opening
>> the file just once, with O_RDWR.  If the file is not
>> a regular file, we might have to give up and open such
>> a file twice, but that should be rare.
>>
> 
> The race would be unlikely and
> only fallback to the existing operation
> of slower failure.
> 
> Though I suppose opening the file is a
> more direct check and would also obviate the
> need to check for writeability of the containing dir
> in the case of a non existent file.
> 
> OK I'm leaning towards an early open so.
> 
> As for cleaning up an empty created file,
> `sort` already has an exit_cleanup() function,
> so we can unlink there.
> 
> I'm not sure it's worth tuning the in==out case TBH.

So I didn't bother unlinking created empty files
as this is problematic in the presence of symlinks.
To mitigate this I create the output after all option
validation is done, just before sort/merge process is started.

Also we must be careful to handle the `sort -o missing missing` case.
I.E. we don't want to create an empty file, resulting in the
above failing to notice the missing file and returning succesfully.
So to avoid that I explicitly check all inputs are readable first.
In addition to catering for the above case, it's a general improvement
to avoid redundant processing.  That was already handled in the merge case,
but in the sorting case only a stat was done as a side effect
of input size checking, and that didn't handle the case
where input was present but unreadable.

Patch attached.

cheers,
Pádraig.

Attachment: sort-exit-early.diff
Description: Text document


--- End Message ---

reply via email to

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