On 7/28/2011 10:51 AM, Christoph Hellwig wrote:
[...]
> I'd suggest to completely drop the stat check, and use the ext2 branch
> unconditionally. The ioctl is suppored by all major filesystems.
>
> This also means we can make the test generic, maybe with a _notrun
> instead of an error if FS_IOC_GETFLAGS/FS_IOC_SETFLAGS isn't supported.
I changed it according to your suggestion:
- Get rid of the check for the specific filesystem type.
- Always use FS_IOC_GETFLAGS/FS_IOC_SETFLAGS. This code is inside an
'#ifdef FS_IOC_SETFLAGS" block in order to never fail compilation.
- Without support for FS_IOC_SETFLAGS, the test completes with _notrun.
What is your opinion about the issue that the test 079 fails on
ext2, ext3, ext4 and btrfs filesystems. Only XFS filesystems succeed
test 079.
mkdir("/mnt3/foo/append-only.d", 0777) = 0
open("/mnt3/foo/append-only.d", O_RDONLY) = 3
ioctl(3, FS_IOC32_SETFLAGS or FS_IOC_SETFLAGS, 0x7fffaf60b07c) = 0
(this ioctl enables FS_APPEND_FL for the directory)
close(3)
open("/mnt3/foo/append-only.d/newfile-0", O_RDWR|O_CREAT, 0666) = -1
EPERM (Operation not permitted)
One issue is that the file is there (the creation did succeed but
the open for writing did not) what IEEE 1003.1-2004 prohibits
(open() must not create or modify any files if -1 is returned).
The difference between the filesystems is whether the append-only
flag from the directory is inherited to the newly create file inside
that directory. XFS does not inherit that append-only flag, ext2,
ext3, ext4 and btrfs do inherit it.
Test 079 fails when the open("/mnt3/foo/append-only.d/newfile-0",
O_RDWR|O_CREAT, 0666) fails due to the O_RDWR flag. The O_RDWR
flag lets the open() fail when the file has the append-only flag
set. On one type of filesystem the flag is inherited from the
directory, on the other type it is not. Test 079 expects that flag
to not be inherited.
What is your opinion? I would prefer to either change the test to
detect whether the append-only flag is inherited and then interpret
the following system call result depending on the state of the flag,
or to force the flag to a defined state to be independent of the
inheritance behaviour.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
