Re: Internal 'echo' command doesn't handle I/O errors on close file

[Andrey Zaitsev]

23 апреля 2012 г. 20:50 пользователь Andreas Schwab
<schwab@linux-m68k.org>написал:

> Greg Wooledge <wooledg@eeg.ccf.org> writes:
>
> > On Mon, Apr 23, 2012 at 02:38:47PM +0400, Andrey Zaitsev wrote:
> >> Strace show that errors from /bin/bash were ignored:
> >>
> >> [user@host ~]# strace echo "bla-bla-bla" > /mnt/fs/out.txt
> >> execve("/bin/echo", ["echo", "bla-bla-bla"], [/* 22 vars */]) = 0
> >
> > If you want an strace of the internal echo, you have to do it this
> > way:
> >
> > # strace bash -c 'echo "bla-bla-bla" > /mnt/fs/out.txt'
> >
> > In fact it's the redirection whose failure you really care about.
>
> The redirection itself won't fail, unless the device is out of inodes.
>
> Andreas.
>
> --
> Andreas Schwab, schwab@linux-m68k.org
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
>

>On Mon, Apr 23, 2012 at 06:50:31PM +0200, Andreas Schwab wrote:
>> The redirection itself won't fail, unless the device is out of inodes.
>Greg Wooledge wrote:
>Ah... OK, I can see how that might be the case.  Or depending on the
>file system implementation, it might fail if an additional block of
>disk space would need to be allocated to the directory to hold the
>new filename.  Which should be somewhat rare in practice.

Hello
This can occur often when target file placed on some networking file system
or on FUSE, or when used disk quota.

>From close's man:
      "Not  checking the return value of close() is a common but
nevertheless serious programming error.  It is quite possible that errors
on a previous write(2) operation are first reported at the final close().
Not checking the return value when closing the file may lead to silent loss
of data. This can especially be observed with NFS and with disk quota."