> You realie that except for filesystems that are legacy compatible with > Microsoft, the concept of "hidden file" simply doesn't exist? So when > you say: Sorry, but the concept of hidden files exists in ext3, in fact files which name starts with a dot are hidden. > "Must?" Bzzzt! There will be many filesystems that have no place to > store a hidden attribute, where the concept doesn't exist. For > example, NFSv3 simply doesn't possess anything vaguely like a hidden > attribute. And even if we made a non-standard extension to NFSv3, it > wouldn't be supported by the millions and millions of non-Linux NFSv3 > implementations. if the filesystem does not support hidden files the result of the call to that interface will be always "false", so no problem here. > 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". All applications support permission denied, for instance when you try to write a file which is read-only for you. If you want it's still possible to add a function that checks the ability to support hidden files > It also means that if a desktop toolkit wants to depend on all > filesystems supporting the concept of hidden files, that's probably a > really bad idea, since it simply doesn't match with reality. Cannot understand the point. Hidden files exist (I think in most filesystems, either with attributes or filenames), so they are reality -- 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
