On Tue, Dec 22, 2009 at 9:29 PM, Marvin Humphrey <mar...@rectangular.com> wrote:
> On Tue, Dec 22, 2009 at 09:03:42PM -0800, Joshua ben Jore wrote:
>> On Tue, Dec 22, 2009 at 4:29 PM, Michael G Schwern <schw...@pobox.com> wrote:
>> > A little experimentation with a small disk image shows that close() will
>> > error if there's no disk left.  No need to check every print.  And a 
>> > close()
>>
>> You have to check every print. Most prints will just extend the buffer
>> but some prints will flush the buffer and return a real
>> success/failure.
>
> But when print() or flush() fails, doesn't that put the filehandle into a
> state where close() will always fail?
>
> From the perldocs for close():
>
>     Closes the file or pipe associated with the file handle, flushes the IO
>     buffers, and closes the system file descriptor.  Returns true if those
>     operations have succeeded and if no error was reported by any PerlIO
>     layer.
>
> If flushing the IO buffers fails once because the disk is full, I don't expect
> that it would succeed in the future, right?
>
> I've been using the technique of skipping checks on print() but checking
> close() for a while now.  Maybe I've been lucky, but it seems to have been
> pretty successful at detecting disk-full conditions.  The only downside is
> that you don't know as soon as it happens -- you only know when you close() --
> but depending on how your program is structured, that's usually not a problem.

I'd never thought to try this. What you suggested appears to work well
enough for ordinary code like EU::MM.

It fails interestingly. The first print that flushes the buffer
returns ENOSPC. Subsequent prints that don't flush the buffer return
EBADF. If the buffer flushes start succeeding the print calls still
keep erroneously returning EBADF. The close seems to return ENOSPC or
EBADF just like the print regardless of whether it is succeeding. The
EBADF results were all wrong. They ought to be have been ENOSPC or
success.

Josh

Reply via email to