lkml.org 
[lkml]   [2005]   [Jun]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: why does fsync() on a tmpfs directory give EINVAL?
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/

\
 
 \ /
  Last update: 2005-06-17 06:50    [W:0.043 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site