Hi Szaka, > Here is how I see things. > > The anomymous, untitled NTFS developer (junior, senior, etc?)
Clearly, Larry didn't want to expose him to the general public. Not every dev has the time or inclination to do what is effectively public relations (PR) on the side. Feel free to start a conversation of your own, BTW. Microsoft is a very open organization, as organizations go, filled with a lot of well-meaning (honestly) and smart devs. Upper management may be a realm of backstabbing politics and nasty machinations, but I have nothing but good words for the developers. > 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. Yes, it's an off-the-cuff reply. However, devs in general (not just at MS) don't have the authority to e.g. mail out internal specifications to strangers who email in questions, so I'm not sure how you could reasonably expect any more. > It also doesn't make > sense, since Microsoft claims NTFS is POSIX which should mean only '\0' and > '/' are disallowed [*]. What a company claims (A), what a company supports (B) and what a company has implemented (C) are three different things. The difference between B and C is quality, aka bugs; the difference between A and B is rhetoric; and the difference between A and C is a gulf. If NTFS-3G tries to make a claim[1] that it is cross-compatible with NTFS as implemented on other platforms (i.e. NT/etc.), which target do you think, in good conscience, should be aimed at? In my opinion, if one claims compatibility, one must target what is implemented with a plan for what is supported, and not pay too much attention to what is claimed. To target what is claimed is to build your foundation on aspirations, not reality. I work for a software company (CodeGear, a subdivision of Borland) that makes development software for Windows. Specifically, I work on the Delphi compiler. When we, as professional software engineers[2], make software that is compatible with a platform, we use a term "bug compatible": if the platform has a bug, we make our software compatible with that bug. To do otherwise wouldn't help anybody except the developer's ego, to give them an immature and selfish feeling of occupying some kind of moral high ground. http://en.wikipedia.org/wiki/Bug_compatibility [1] http://ntfs-3g.org/ "The purpose of the project is to develop, continuously quality test and support a trustable, feature rich and high performance solution for hardware platforms and operating systems whose users need to reliably interoperate with NTFS." There's a very important phrase in there, worth repeating: "users need to reliably interoperate with NTFS". Forget MS: think of the users. [2] I don't and legally can't speak for CodeGear/Borland. > I'm also aware that there is at least one way to bypass filename > restricting filetering but I don't know what cases it covers and > on what level it happens. > Larry Osterman gave no technical explanation but submiting a chkdsk bug > report is very much appreciated. I'm waiting for the outcome. Is it > possible to follow it somewhere and get a notification when a fix is > released if it's done? I have no idea. CHKDSK isn't obviously visible on e.g. http://connect.microsoft.com so my guess would be no. > > I got another reply from the other developer I contacted, Malcom Smith: > > Thanks. Unfortunately I also can't find any information about him. http://google.com/search?q=malcom+smith+ntfs first result points at a pointer to his blog: http://blogs.msdn.com/because_we_can/default.aspx "For those who don't know me, I have transitioned to work on NTFS proper. It's fun, technical work, but it's also maintenance, something which just seems less exciting for a public audience. As a result, I don't have quite so much to talk about." I contacted him through the contact link on this blog: http://blogs.msdn.com/because_we_can/contact.aspx You can too. > Please dont' get me wrong, I'm trying pretty hard. My snarky reply has been duly censored! > I don't mean this is a bad thing but we don't make > changes without strong, credible backing and fully understanding the > technical background and its consequences. Microsoft devs (or indeed devs from pretty much anywhere) don't have the authority to give "backing". What do you need? A patent cross-licensing deal with MS? I don't have the ability to get that, sorry. An internal design doc or spec from MS? I don't think you can legally get that without the cross-licensing deal at a minimum. So what do you need? > > On Thu, 13 Mar 2008 23:12:25 -0700, "Malcolm Smith (NTFS)" > > > > > 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. CreateFile is a Win32 API for creating and opening files and devices which is generic across different file systems. Malcom's comment here implies that the compatiblity issue with NT and 0x3F is not in the Win32 subsystem (which could be solved by going through a different subsystem like POSIX), but rather is a limitation with MS's implementation of NTFS at the driver level, living in kernelspace. > > > If Windows interop is a primary criteria for NTFS-3G, > > The primary criteria is NTFS POSIX interoperibility. FWIW, that's not the way your website puts it. Anyway, what does that mean? Where is this NTFS POSIX standard that you claim to be interoperable with, who uses it, and why is it the most important thing for your users? I thought POSIX was an *API* standard, not a hard disk storage format standard. I've already described how the NT POSIX subsystem translates characters into private use area of Unicode, so it can achieve POSIX compatibility at the API level (the only level that matters for POSIX) without actually using the relevant characters (which would compromise compatibility with Windows itself). What format stuff gets stored physically on disk is pretty much beside the point, the way I see it: POSIX is an API standard relating to *software*, not hardware. > If Microsoft can't > fulfill this then they either should fix their POSIX compatibility or not > to claim it. When you say this, here's what I read: you are letting *Microsoft's* claims hurt *your* users for no good reason that I can see. Why are Microsoft's claims more important than your users? Heck, not even Linux claims full POSIX compatibility. > [*] Here I tried to find Microsoft references and ... I couldn't find. [...] > I think the subtitle can be indeed misunderstood, which may make somebody > believe in POSIX conformance when in fact it's only partial compliance as > explained later on. NT was (at one time) actually certified, but mostly for governmental contract reasons: http://www.gcn.com/print/14_23/31557-1.html "A recent ruling by the General Services Administration Board of Contract Appeals affirmed the Posix compliance of Microsoft Corp.'s Windows NT operating system. "Several months ago, the National Institute of Standards and Technology certified NT as complying with the Posix standard, Federal Information Processing Standard 151-2 for open operating systems." But to be frank, the whole POSIX thing is a red herring. What's important is the users, not POSIX compliance or non-compliance. > 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 ... I don't have the detailed statistics, but I would venture that that is a niche use of NTFS-3G - an important niche, but a niche nonetheless. I believe it should be a mount option, a kind of "raw" mode, which defaults to off. I would hazard a guess that most users of NTFS-3G are using it because they are dual-booting Windows and Linux. > If chkdsk is "fixed" then we should revise this issue. I have two things to say about this: 1) An NTFS engineer, Malcom Smith, has already stated that: "There are, however, many cases where chkdsk can be overly tolerant - it was never really meant as a validation tool." It therefore seems to me that you are misusing CHKDSK. 2) Why are you making helping your users conditional on Microsoft taking some action? Recall Voltaire: "the perfect is the enemy of the good". And please, think of the users! They're the ones who matter. -- Barry -- http://barrkel.blogspot.com/ ------------------------------------------------------------------------- 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
