On Fri, 2008-10-10 at 18:01 -0400, Christoph Hellwig wrote: > On Fri, Oct 10, 2008 at 05:57:22PM -0400, Theodore Tso wrote: > > The best you might be able to get is an interface that allows an > > application to get or set the hidden attribute if is supported --- but > > the application must be willing to accept a permission denied error > > (some filesystems may only permit people with certain access right or > > on some ACL to set the attribute), or a "operation not supported" > > failure, for those filesystems that simply have not concept of "hidden > > file". > > Yes. he best thing you could do is to add support for the > FAT_IOCTL_GET_ATTRIBUTES/FAT_IOCTL_SET_ATTRIBUTES ioctls to other > windows-heritage filesystems. Feel free to submit patches. This is a bad interface for most apps. You need to open each file to get a fd to pass to ioctl. This is problematic if for instance you don't have read access to the file. So, you really want a path-based operation for this. Its also very expensive since it causes lots of extra I/O. For instance, a file manager that wants to hide files with the hidden attribute set (on filesystems which support this) would have to open all files just so it could try calling this ioctl. To avoid this you can do some filesystem matching and hard code the lists of filesystems that supports this call, but having a clean API would be nicer and more efficient. Now, you could argue (and unsurpisingly you do) that ext3 & co doesn't have a hidden attribute, but that doesn't mean I can ignore actual users who have data on other filesystems and want to integrate nicely with them. This includes not showing weird system files that are normally hidden on said filesystems. -- 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
