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
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).
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/