Messages in this thread | | | Date | Thu, 16 Jun 2005 21:46:06 -0700 | From | Chris Wedgwood <> | Subject | Re: 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/
| |