This got sent directly to Szabolcs ([EMAIL PROTECTED]) by mistake. I'm re-sending it for the list.
---------- Szabolcs Szakacsits wrote: > Hi, > > Thank you Barry for your research! > > Here is how I see things. > > The anomymous, untitled NTFS developer (junior, senior, etc?) wrote that > "as far as I know" and "0x3F is explicitly reserved as a wild card for NTFS > on Windows and is explicitly blocked from being used in a file name.". > > The first part is not a reliable technical reply and the second one is too > vague and suspicious since Unix also has many wild cards, still none of its > file systems reserve and block them in filenames. Well, in windows the shell (and indeed almost everything) passes wildcards directly to the kernel. The braindeadacity of this is overwhelming, since it means that there are several perfectly fine characters you simply cannot use in filenames. Now, this should actually simply cover the findfirst/next/close win32 API, so that it would work like glob. However, because the shell has traditionally had very little support for quoting and escaping, the practice got extended to all file name functions. That, and it's a remnant from DOS. > It also doesn't make > sense, since Microsoft claims NTFS is POSIX which should mean only '\0' and > '/' are disallowed [*]. Only when using the posix filesystem namespace, which 99% of all windows programs don't. When using the ntdll kernel interface, you can access files through whatever namespace you prefer. Interestingly enough, the win32 namespace lives in the "\??\" prefix, so "c:\test.dat" would be "\??\c:\test.dat" in the win32 namespace. I don't remember the POSIX prefix, but it's accessed in a similar way IIRC. > [...] >>> This is interesting. I did some research and it turns out that the >>> NTFS driver will fail creates/opens with wildcards (ie., you can't >>> bypass Win32 and do this.) > > I don't understand how Win32 comes to the picture. The issue is only NTFS > and POSIX. In Windows NT, the win32 subsystem is actually a library like libc. Therefore, you could choose to talk directly to the kernel interface library (ntdll.dll). If the check was simply added in the win32 subsystem, this would allow you to skip the check altogether when talking to ntdll. Malcolm suggests that the check is implemented directly in the driver, not in win32. This is broken, of course. > And here is our problem. Windows is massively plagued with all kind of > security problems by viruses, root kits etc which exploit Windows > shortcomings to hide themself. The open source NTFS-3G is widely used > in security softwares because it can access and remove them. > > You're asking to drop the above highly important feature to become > compatible with the non-POSIX complaint NT "POSIX" subsystem. That > won't be easy but I'll think about it ... The best solution would be a parameter for mount, I think. How about wildcard_safeguard=[0|1]? By defaulting to 1, end users will be happy. By allowing 0, experts will be happy. -- Regards, Christian Iversen ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ ntfs-3g-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
