With 3. Wine's FindFirstFile and FindNextFile wont't be able to report
hidden files and Win32 programs could rely on that instead of using
hard-coded filenames.
If I'm not mistaken these functions return all files and put file flags
in a struct. User apps are responsible of the hiding.
One could argue that Win32 programs could rely on the file flags being
reported correctly, but I find this far less probable.
If one goal is to allow Wine to implement the Win32 syscalls as correctly as
possible 3. is not an option IMHO.
Moreover I don't like the idea of files readable but not findable by common
tools, seems broken to me.
2. will lead to entries in FAQ:
Q: What does the "unhide" option mean in my /etc/fstab ?
A: Lengthy explanation on ISO9660, Windows FS versus Unix FS and so on...
1. will do what Linux already does for other FAT/NTFS contents, simply show
the info to the users even if Windows' tools hide it by default.
Personnaly I would choose 1. (I prefer short FAQs).
LB.
-
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/