Skip to contentSkip to conversation

Floppy disk strange behavior

DISCUSSION [email protected] 2 participants 2 messages Jan 9, 2001 VFS

lore
Share & tools
lore
#0 lore raw
Quoted 4 lines
Quoted 1 line

dd: advancing past 1 blocks in output file `/dev/fd0': Permission denied

dd bug. It tries to ftruncate() the output file and gets all upset when kernel refuses to truncate a block device (surprise, surprise).

Yes. But EPERM means that something is wrong with privileges. One would expect EINVAL or so when something is wrong with the way the routine was called.

Let me find my docs :-)

===== austin - d5 ============================================
...
If fildes 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( ).
...
If fildes refers to a directory, ftruncate( ) shall fail.
...
If fildes refers to any other file type, except a shared memory object, the result is unspecified.
=============================================================

No info on errors here.

===== Digital Unix man ======================================
...
The path parameter must point to a pathname which names a regular file for which the calling process has write permission.
...
[EINVAL] The file is not a regular file
=============================================================

So, as was to be expected, other systems use EINVAL in this situation, and so should we.

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

#1 lore raw

truncate() error values (was Re: Floppy disk strange behavior)

Quoted 6 lines · On Wed, 10 Jan 2001 [email protected] wrote:
Quoted 4 lines
Quoted 1 line

dd: advancing past 1 blocks in output file `/dev/fd0': Permission denied

dd bug. It tries to ftruncate() the output file and gets all upset when kernel refuses to truncate a block device (surprise, surprise).

Yes. But EPERM means that something is wrong with privileges.

EACCES, actually.

Quoted 2 lines

One would expect EINVAL or so when something is wrong with the way the routine was called.

Oh, agreed. Patch I've sent to Linus and posted on l-k more than a month ago:

fs/open.c +7 -2
diff -urN rc12-pre5/fs/open.c rc12-pre5-truncate/fs/open.c
@@ -102,7 +102,12 @@
 		goto out;
 	inode = nd.dentry->d_inode;
 
-	error = -EACCES;
+	/* For directories it's -EISDIR, for other non-regulars - -EINVAL */
+	error = -EISDIR;
+	if (S_ISDIR(inode->i_mode))
+		goto dput_and_out;
+
+	error = -EINVAL;
 	if (!S_ISREG(inode->i_mode))
 		goto dput_and_out;
 
@@ -163,7 +168,7 @@
 		goto out;
 	dentry = file->f_dentry;
 	inode = dentry->d_inode;
-	error = -EACCES;
+	error = -EINVAL;
 	if (!S_ISREG(inode->i_mode) || !(file->f_mode & FMODE_WRITE))
 		goto out_putf;
 	error = -EPERM;

That's test12-pre5. And yes, the case of files opened with O_RDONLY should be -EINVAL according to
* our own manpages
* POSIX
* *BSD behaviour
* Solaris behaviour
* manpages of all Unices I've seen.
-EACCES is wrong here. More logical, but...

Linus, I realize that we have a moratorium on patches. It's certainly not a critical one, but it probably ought to be applied at some point. Could you tell what time would be OK for resubmitting it? All it changes is
* error returned for truncate() on directories (EACCES -> EISDIR)
* error returned for truncate() on other non-file (EACCES -> EINVAL)
* error returned for ftruncate() on O_RDONLY fds (EACCES -> EINVAL)
* error returned for ftruncate() on non-files (EACCES -> EINVAL)
In all cases new error values are what we are required to do by POSIX, SuS, our own manpages, manpages of other Unices and actual behaviour of other Unices.

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