Re: [patch] s_maxbytes handling
Linus writes: 0 is EOF _for_reads_. For writes it is not very well defined Hmm. So -EFBIG is certainly the preferable return value, Yes. The Austin 6th draft writes EFBIG: An attempt was made to write a file that exceeds the implementation-defined maximum file size or the process' file size limit, and there was no room for any bytes to be written. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] s_maxbytes handling
Linus Torvalds wrote: > [deletia] > > So returning 0 for write() is usually a bad idea - exactly because it > does not have very well-defined semantics. So -EFBIG is certainly the > preferable return value, and seems to be what SuS wants, too. And what LFS wants too: 2.2.1.27 write() and writev() DESCRIPTION For regular files, no data transfer will occur past the offset maximum established in the open file description associated with fildes. ERRORS These functions will fail if: [EFBIG] The file is a regular file, nbyte is greater than 0 and the starting position is greater than or equal to the offset maximum established in the open file description associated with fildes. Note: This is an additional EFBIG error condition. -- David N. Lombard - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] s_maxbytes handling
In article <[EMAIL PROTECTED]>, Alan Cox <[EMAIL PROTECTED]> wrote: >> > verification tests. So unless you can cite page and paragraph from SuS and >> > the LFS spec I think the 0 might in fact be correct.. >> >> I don't know the standards Alan, but returning zero >> from write() when f_pos is at s_maxbytes will make >> a lot of apps hang up. dd, bash and zsh certainly do. > >> Are they buggy? Should they be testing the return value >> of write() and assuming that zero is file-full? > >0 is an EOF. 0 is EOF _for_reads_. For writes it is not very well defined (except for the special case of a zero-sized write to a regular file). For writes, 0 has historically been what Linux has returned for various "disk full" conditions, and seems to be what programs such a "tar" actually expected for end of disk. Also, traditionally a lot of UNIXes returned 0 when O_NDELAY was set and they couldn't write anything (ie the modern EAGAIN). An application seeing a zero return from a write with a non-zero buffer size cannot really assume much about what it means. The best you can probably do is to fall back and say "no more space on device", but obviously a lot of programmers who are used to testing only for _real_ errors will not even think about considering 0 an error value. So returning 0 for write() is usually a bad idea - exactly because it does not have very well-defined semantics. So -EFBIG is certainly the preferable return value, and seems to be what SuS wants, too. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] s_maxbytes handling
> > verification tests. So unless you can cite page and paragraph from SuS and
> > the LFS spec I think the 0 might in fact be correct..
>
> I don't know the standards Alan, but returning zero
> from write() when f_pos is at s_maxbytes will make
> a lot of apps hang up. dd, bash and zsh certainly do.
> Are they buggy? Should they be testing the return value
> of write() and assuming that zero is file-full?
0 is an EOF.
> The s_maxbytes logic is different from the
> MAX_NON_LFS logic:
>
> /*
> * LFS rule
> */
> if ( pos + count > MAX_NON_LFS && !(file->f_flags_LARGEFILE)) {
> if (pos >= MAX_NON_LFS) {
> send_sig(SIGXFSZ, current, 0);
> goto out;
> }
>
> This makes more sense. If the file is full, and
> you're trying to grow it, you fail.
The spec says of write
DESCRIPTION
For regular files, no data transfer will occur past the offset
maximum established in the open file description associated with
fildes.
[EFBIG]
The file is a regular file, nbyte is greater than 0 and the
starting position is greater than or equal to the offset
maximum established in the open file description associated
with fildes.
Which seems to say to me that if we write > 0 bytes and we start at or
on the boundary we should error - which would agree with your change.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch] s_maxbytes handling
If ->f_pos is positioned exactly at sb->s_maxbytes, a non-zero-length
write to the file doesn't write anything, and write() returns zero.
Consequently applications which try to append to a file which
is s_maxbytes in length hang up, because write() just keeps
on returning zero.
We need to return -EFBIG if ->f_pos is at s_maxbytes and
the length is non-zero.
--- linux-2.4.5-pre4/mm/filemap.c Mon May 21 20:03:03 2001
+++ linux-akpm/mm/filemap.c Tue May 22 22:34:41 2001
@@ -2571,11 +2571,13 @@
* Linus frestrict idea will clean these up nicely..
*/
- if (pos > inode->i_sb->s_maxbytes)
- {
- send_sig(SIGXFSZ, current, 0);
- err = -EFBIG;
- goto out;
+ if (pos >= inode->i_sb->s_maxbytes) {
+ if (count || pos > inode->i_sb->s_maxbytes) {
+ send_sig(SIGXFSZ, current, 0);
+ err = -EFBIG;
+ goto out;
+ }
+ /* zero-length writes at ->s_maxbytes are OK */
}
if (pos + count > inode->i_sb->s_maxbytes)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch] s_maxbytes handling
If -f_pos is positioned exactly at sb-s_maxbytes, a non-zero-length
write to the file doesn't write anything, and write() returns zero.
Consequently applications which try to append to a file which
is s_maxbytes in length hang up, because write() just keeps
on returning zero.
We need to return -EFBIG if -f_pos is at s_maxbytes and
the length is non-zero.
--- linux-2.4.5-pre4/mm/filemap.c Mon May 21 20:03:03 2001
+++ linux-akpm/mm/filemap.c Tue May 22 22:34:41 2001
@@ -2571,11 +2571,13 @@
* Linus frestrict idea will clean these up nicely..
*/
- if (pos inode-i_sb-s_maxbytes)
- {
- send_sig(SIGXFSZ, current, 0);
- err = -EFBIG;
- goto out;
+ if (pos = inode-i_sb-s_maxbytes) {
+ if (count || pos inode-i_sb-s_maxbytes) {
+ send_sig(SIGXFSZ, current, 0);
+ err = -EFBIG;
+ goto out;
+ }
+ /* zero-length writes at -s_maxbytes are OK */
}
if (pos + count inode-i_sb-s_maxbytes)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] s_maxbytes handling
In article [EMAIL PROTECTED], Alan Cox [EMAIL PROTECTED] wrote: verification tests. So unless you can cite page and paragraph from SuS and the LFS spec I think the 0 might in fact be correct.. I don't know the standards Alan, but returning zero from write() when f_pos is at s_maxbytes will make a lot of apps hang up. dd, bash and zsh certainly do. Are they buggy? Should they be testing the return value of write() and assuming that zero is file-full? 0 is an EOF. 0 is EOF _for_reads_. For writes it is not very well defined (except for the special case of a zero-sized write to a regular file). For writes, 0 has historically been what Linux has returned for various disk full conditions, and seems to be what programs such a tar actually expected for end of disk. Also, traditionally a lot of UNIXes returned 0 when O_NDELAY was set and they couldn't write anything (ie the modern EAGAIN). An application seeing a zero return from a write with a non-zero buffer size cannot really assume much about what it means. The best you can probably do is to fall back and say no more space on device, but obviously a lot of programmers who are used to testing only for _real_ errors will not even think about considering 0 an error value. So returning 0 for write() is usually a bad idea - exactly because it does not have very well-defined semantics. So -EFBIG is certainly the preferable return value, and seems to be what SuS wants, too. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] s_maxbytes handling
Linus Torvalds wrote: [deletia] So returning 0 for write() is usually a bad idea - exactly because it does not have very well-defined semantics. So -EFBIG is certainly the preferable return value, and seems to be what SuS wants, too. And what LFS wants too: 2.2.1.27 write() and writev() DESCRIPTION For regular files, no data transfer will occur past the offset maximum established in the open file description associated with fildes. ERRORS These functions will fail if: [EFBIG] The file is a regular file, nbyte is greater than 0 and the starting position is greater than or equal to the offset maximum established in the open file description associated with fildes. Note: This is an additional EFBIG error condition. -- David N. Lombard - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] s_maxbytes handling
Linus writes: 0 is EOF _for_reads_. For writes it is not very well defined Hmm. So -EFBIG is certainly the preferable return value, Yes. The Austin 6th draft writes EFBIG: An attempt was made to write a file that exceeds the implementation-defined maximum file size or the process' file size limit, and there was no room for any bytes to be written. Andries - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] s_maxbytes handling
verification tests. So unless you can cite page and paragraph from SuS and
the LFS spec I think the 0 might in fact be correct..
I don't know the standards Alan, but returning zero
from write() when f_pos is at s_maxbytes will make
a lot of apps hang up. dd, bash and zsh certainly do.
Are they buggy? Should they be testing the return value
of write() and assuming that zero is file-full?
0 is an EOF.
The s_maxbytes logic is different from the
MAX_NON_LFS logic:
/*
* LFS rule
*/
if ( pos + count MAX_NON_LFS !(file-f_flagsO_LARGEFILE)) {
if (pos = MAX_NON_LFS) {
send_sig(SIGXFSZ, current, 0);
goto out;
}
This makes more sense. If the file is full, and
you're trying to grow it, you fail.
The spec says of write
DESCRIPTION
For regular files, no data transfer will occur past the offset
maximum established in the open file description associated with
fildes.
[EFBIG]
The file is a regular file, nbyte is greater than 0 and the
starting position is greater than or equal to the offset
maximum established in the open file description associated
with fildes.
Which seems to say to me that if we write 0 bytes and we start at or
on the boundary we should error - which would agree with your change.
Alan
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
