On Sun, 23 Mar 2008, Christian Iversen wrote:
> Szabolcs Szakacsits wrote:
> >
> > 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 I knew then I'd have explicitely mention them. I never used Windows
but I talked with people who handle such files (e.g. security companies).
I can talk with them. But it very well could be that they are bypassing
Microsoft code.
> Maybe no one knows. I wouldn't actually be surprised. From what I can
> gather, internal communication in Microsoft is kept to a minimum.
Yes, that's my impression too. The Interix developers didn't know how to
handle the unvalidated UTF16 filenames and instead of communicating and
solving the problem they introduced an incompatible workaround.
> 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.
And then different distros/users would use different options which would
result interfering behaviours which can end up handling (e.g. deleting)
different files what the user intended. Then a new Berry would come again
"with the torch showing us the light" and explaining long how narrow
minded, prejudiced we are.
So at the end of the day somebody will be always upset. If so, then why not
to use the simplest solution, after all, the problem is not on the Linux
side (we must be able to handle __all__ filenames) but on the Windows one?
> 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?
Not only creation but all lookups with the workarounds if files with the
(non-)translated characters exist already. But I think the code would be
the easier part. The harder is keep explaining the complexity, the
misunderstandings, the real and virtual loss of files, etc.
Regards,
Szaka
-------------------------------------------------------------------------
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
