Szabolcs Szakacsits wrote: > Hi Christian, > > On Fri, 14 Mar 2008, Christian Iversen wrote: >> 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. > > Very interesting. And sad at the same time.
Mostly sad, I think :-) >> 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. > > Yes, I remember some escaping and hoped it may overcome the issue if one > used the proper function from a proper library. What "proper" functions from what "proper" library are you referring to? If you mean ntdll.dll, it's technically unsupported to call it directly. I've coded for it extensively, though. It has many advantages. Avoiding the braindead FindFirst/Next/Close is one major advantage. >> Malcolm suggests that the check is implemented directly in the driver, >> not in win32. This is broken, of course. > > Thanks, now I see. That's indeed very unfortunate. It is, but so is so much of the windows api. > I know that the developer who wrote most of NTFS (about 500,000 source > lines) left Microsoft a few years ago and many people felt this as a great > loss. All other NTFS developers left long ago. My impression (debugging > interoperability problems, tracking Microsoft NTFS knowledgebase articles, > fixes) is that Microsoft doesn't really have strong NTFS competence > anymore. Eek. That would also explain why they never finished WinFS. > Though this filename issue would be very easy to check if somebody has > access to the source code. But perhaps not if there are unpublished, > internal workarounds. Maybe no one knows. I wouldn't actually be surprised. From what I can gather, internal communication in Microsoft is kept to a minimum. Because everything is proprietary, only select few people actually have access to much of the source code at once. Most people can only read code in the specific module they are working on. > I also delt with Interix developers in the past. They were breaking the GNU > binutils toolchain what I had to fix since utils were segfaulting on PEI > files. My opinion wasn't very high on them. They objected heavily to the > fixes but couldn't point out any problem, nor they could came up with a > working fix. In the end the maintainers gave me right and my PEI fixes got > applied to binutils. > >> How about wildcard_safeguard=[0|1]? By defaulting to 1, end users will >> be happy. By allowing 0, experts will be happy. > > Optional behavior would be definitely possible if somebody codes and > maintains it. But I'm not sure users would be happier for the '1' case > because that would break many Linux utilities. Well, how about: wildcards=allow|deny|translate Each has it's set of problems. Allow would be the current behaviour. Deny would be pretty simple to implement, and translate would be the proposed patch. I think this pretty much (only?) applies to file creation. I don't see how it would be a hugely complex block of code to maintain. Am I wrong? > Thank you for the email and your explanation. The situation is much > clearer for me now. You're certainly welcome. -- Med venlig hilsen 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
