Re: why does fsync() on a tmpfs directory give EINVAL?

[Chris Wedgwood <cw@f00f.org>]

On Thu, Jun 16, 2005 at 06:57:54PM -0700, Andrew Morton wrote:

> hm, what a lot of filesystems.
>
> bix:/usr/src/linux-2.6.12-rc6> grep -rl simple_dir_operations .
> ./drivers/usb/gadget/inode.c
> ./drivers/usb/core/inode.c
> ./drivers/isdn/capi/capifs.c
> ./drivers/oprofile/oprofilefs.c
> ./drivers/misc/ibmasm/ibmasmfs.c
> ./fs/libfs.c
> ./fs/debugfs/inode.c
> ./fs/autofs/inode.c
> ./fs/devpts/inode.c
> ./fs/hugetlbfs/inode.c
> ./fs/ramfs/inode.c
> ./include/linux/fs.h
> ./net/sunrpc/rpc_pipe.c
> ./kernel/cpuset.c
> ./security/selinux/selinuxfs.c
> ./ipc/mqueue.c
> ./mm/shmem.c
>
> I can't think of any reason why any of these would want fsync(dir_fd) to
> return -EINVAL.

Logically I think we can only expect 'real' filesystems with block
devices or similiar behind them to do something with fsync and
everyone else to be more or less undefined.

Undefined creates problems I guess so I guess simple_dir_operations
could return 0 (it sorta does make sense, if you have no backing store
you are always in-sync?).

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