The problem: NTFS-3G writes filenames containing '?' differently to how NT itself handles filenames containing '?'.
Details: When using the POSIX subsystem, now known as Interix or Services for Unix (SFU), files with '?' (0x3F) in the name are silently converted to use the private area Unicode character 0xF03F. When a file containing a '?' (0x3F) created by NTFS-3G are manipulated from Windows, even using the POSIX subsystem, they cannot be "found". Solution: I suggest that, in the interest of compatibility, NTFS-3G follows the NT POSIX convention and silently transforms 0x3F to and from 0xF03F. Rationale: The alternative is that files created by NTFS-3G are in no way accessible or even deletable from NT, as it appears that the kernel doesn't support '?' in file names. I hope it's obvious that that alternative isn't very desirable. Patch: I've attached a patch to the latest CVS sources from sf.net which does exactly that, using 'cvs diff -u3'. The simple idea behind the patch is that during MB->UCS-2 and UCS-2->MB conversions, 0x3F is replaced with 0xF03F and vice versa. The invariant that should apply is that data referenced with type ntfschar* should never contain 0x3F, and contain 0xF03F instead. Any further suggestions on how to proceed appreciated. -- Barry -- http://barrkel.blogspot.com/
nt-question-compat-2008-03-12_01-53.patch
Description: Binary data
------------------------------------------------------------------------- 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
