Re: 2.4.0-test10 truncate() change broke `dd'

Re: 2.4.0-test10 truncate() change broke `dd'

[Mikael Pettersson]

On Thu, 16 Nov 2000, Alexander Viro wrote:

> And what kind of meaning would you assign to truncate on floppy?

On a block or char device, truncate == lseek seems reasonable.

My guess is that dd uses ftruncate because that's correct for
regular files and has happened to also work (as an alias for
lseek) for devices.

> Use conv=notrunc.

I didn't know about notrunc. Yet another GNU invention?

/Mikael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0-test10 truncate() change broke `dd'

[Alexander Viro]

On Thu, 16 Nov 2000, Mikael Pettersson wrote:

> On Thu, 16 Nov 2000, Alexander Viro wrote:
> 
> > And what kind of meaning would you assign to truncate on floppy?
> 
> On a block or char device, truncate == lseek seems reasonable.

Huh? On regular files ftruncate() doesn't modify the current position
at all. Try and you'll see. Besides, WTF _is_ lseek() for a character
device?

> My guess is that dd uses ftruncate because that's correct for
> regular files and has happened to also work (as an alias for
> lseek) for devices.
> 
> > Use conv=notrunc.
> 
> I didn't know about notrunc. Yet another GNU invention?

Maybe, but I doubt it. Anyway, it made its way into 4.4BSD, it's present
in Solaris, it's in SuS and AFAIK in POSIX. GNU might be the origin, but
it might equally well be a BSDism.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0-test10 truncate() change broke `dd'

[Andries Brouwer]

On Thu, Nov 16, 2000 at 06:53:30AM -0500, Alexander Viro wrote:

> > I didn't know about notrunc. Yet another GNU invention?
> 
> Maybe, but I doubt it. Anyway, it made its way into 4.4BSD, it's present
> in Solaris, it's in SuS and AFAIK in POSIX.

Yes (for 1003.2-1992).
It is not in 4.3BSD.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

2.4.0-test10 truncate() change broke `dd'

[Mikael Pettersson]

2.4.0-test10 broke `dd' for block devices, due to the following
change to do_sys_truncate & do_sys_ftruncate:

diff -u --recursive --new-file v2.4.0-test9/linux/fs/open.c linux/fs/open.c
--- v2.4.0-test9/linux/fs/open.c	Sun Oct  8 10:50:33 2000
+++ linux/fs/open.c	Thu Oct 26 08:11:21 2000
@@ -103,7 +103,7 @@
 	inode = nd.dentry->d_inode;
 
 	error = -EACCES;
-	if (S_ISDIR(inode->i_mode))
+	if (!S_ISREG(inode->i_mode))
 		goto dput_and_out;
 
 	error = permission(inode,MAY_WRITE);
@@ -164,7 +164,7 @@
 	dentry = file->f_dentry;
 	inode = dentry->d_inode;
 	error = -EACCES;
-	if (S_ISDIR(inode->i_mode) || !(file->f_mode & FMODE_WRITE))
+	if (!S_ISREG(inode->i_mode) || !(file->f_mode & FMODE_WRITE))
 		goto out_putf;
 	error = -EPERM;
 	if (IS_IMMUTABLE(inode) || IS_APPEND(inode))

I noticed because I needed to build a boot floppy with an
initial ram disk under 2.4.0-test11pre5. The standard recipe
(Documentation/ramdisk.txt) basically goes:
- dd if=bzImage of=/dev/fd0 bs=1k
  notice how many blocks dd reported (NNN)
- dd if=ram_image of=/dev/fd0 bs=1k seek=NNN
dd implements the seek=NNN option by calling ftruncate() before
starting the write. This is where 2.4.0-test10 breaks, since
ftruncate on a block device now provokes an EACCES error.

Maybe `dd' is buggy and should use lseek() instead, but this has
apparently worked for a long time.

Does anyone know the reason for the S_ISDIR -> !S_ISREG change in test10?

/Mikael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0-test10 truncate() change broke `dd'

[Alexander Viro]

On Thu, 16 Nov 2000, Mikael Pettersson wrote:

> I noticed because I needed to build a boot floppy with an
> initial ram disk under 2.4.0-test11pre5. The standard recipe
> (Documentation/ramdisk.txt) basically goes:
> - dd if=bzImage of=/dev/fd0 bs=1k
>   notice how many blocks dd reported (NNN)
> - dd if=ram_image of=/dev/fd0 bs=1k seek=NNN
> dd implements the seek=NNN option by calling ftruncate() before
> starting the write. This is where 2.4.0-test10 breaks, since
> ftruncate on a block device now provokes an EACCES error.

And what kind of meaning would you assign to truncate on floppy?
 
> Maybe `dd' is buggy and should use lseek() instead, but this has
> apparently worked for a long time.

Use conv=notrunc.

> Does anyone know the reason for the S_ISDIR -> !S_ISREG change in test10?

For one thing, you really don't want it working on pipes. For another -
it's just damn meaningless on devices, symlinks and sockets. Which leaves
regular files.

OTOH, -EACCES looks wrong - for directories we must return -EISDIR and for
sockets ftruncate() should return -EINVAL. Adopting -EINVAL for devices
and pipes may be a good idea... Andries, could you comment on that?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0-test10 truncate() change broke `dd'

[Andries Brouwer]

On Thu, Nov 16, 2000 at 03:02:31AM -0500, Alexander Viro wrote:
: On Thu, 16 Nov 2000, Mikael Pettersson wrote:
: 
:: dd implements the seek=NNN option by calling ftruncate() before
:: starting the write. This is where 2.4.0-test10 breaks, since
:: ftruncate on a block device now provokes an EACCES error.
:: Does anyone know the reason for the S_ISDIR -> !S_ISREG change in test10?
: 
: For one thing, you really don't want it working on pipes. For another -
: it's just damn meaningless on devices, symlinks and sockets. Which leaves
: regular files.
: 
: OTOH, -EACCES looks wrong - for directories we must return -EISDIR and for
: sockets ftruncate() should return -EINVAL. Adopting -EINVAL for devices
: and pipes may be a good idea... Andries, could you comment on that?

Well, open() must return EISDIR upon an attempt to open a
directory for writing. Similarly, truncate() must return EISDIR
for a directory. On the other hand, ftruncate() returns EINVAL
for a fd not open for writing (and not EISDIR).

The behaviour on files other than regular files and shared memory
is mostly undefined.

The Austin draft says (among other things)

=====================================================================
If fd is not a valid file descriptor open for writing, the
ftruncate( ) function shall fail.  If fd refers to a regular file,
the ftruncate( ) function shall cause the size of the file to be
truncated to length. If the size of the file previously exceeded
length, the extra data shall no longer be available to reads on the
file. If the file previously was smaller than this size, ftruncate( )
shall either increase the size of the file or fail.  [XSI-conformant
systems shall increase the size of the file.]  If the file size is
increased, the extended area shall appear as if it were zero-filled.
The value of the seek pointer shall not be modified by a call
to ftruncate( ).  Upon successful completion, if fd refers to a
regular file, the ftruncate( ) function shall mark for update the
st_ctime and st_mtime fields of the file and the S_ISUID and S_ISGID
bits of the file mode may be cleared. If the ftruncate( ) function is
unsuccessful, the file is unaffected.

If fd refers to a directory, ftruncate( ) shall fail.
If fd refers to any other file type, except a shared memory object,
the result is unspecified.

... [shm description omitted] ...

The ftruncate( ) function shall fail if:
EINTR	A signal was caught during execution.
EINVAL	The length argument was less than 0.
EFBIG or EINVAL	The length argument was greater than the maximum file size.
EFBIG	The file is a regular file and length is greater than
	the offset maximum established in the open file description
	associated with fd.
EIO	An I/O error occurred while reading from or writing to a file system.
EBADF or EINVAL The fd argument is not a file descriptor open for writing.
EINVAL	The fd argument references a file that was opened without write
	permission.
EROFS	The named file resides on a read-only file system.
=====================================================================

In other words, it is unspecified what happens on special files.
Of course other error returns are permitted (in non-listed situations).

Digital Unix Man says:
---------------------------------------------------------------------
The truncate() and ftruncate() functions have no effect on FIFO special
files or directories.

EAGAIN	The write operation failed due to an enforced write
	lock on the file.
EINVAL	The file is not a regular file.
---------------------------------------------------------------------


SunOS Man says:
---------------------------------------------------------------------
EINVAL fd is not a valid descriptor of a file open for writing
       or fd refers to a socket, not to a file.
---------------------------------------------------------------------


AIX Man says:
---------------------------------------------------------------------
EINVAL	The file is not a regular file.
---------------------------------------------------------------------


Etc. So - there seems little doubt that if we return an error
for non-regular files, the error should be -EINVAL.

Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/