Hi Barry,
Thank you for the email and patch.
Could you, or somebody else, please do the following test to decide
how we should progress?
Create 254 files using the unpatched driver which file names are single
character ASCII(i) where i=1,...,46,48,...255 then run CHKDSK and tell
us all the file names CHKDSK finds to be incorrect. The log of the CHKDSK
session can be viewed and copy-pasted this way:
http://en.wikipedia.org/wiki/Chkdsk#Viewing_results
We do have known problems with the conversion and these all should be fixed
at the same time.
Bernhard Kaindl has just implemented a new converter recently, in case
you're interested in the current development addressing the conversion
problems:
http://thread.gmane.org/gmane.comp.file-systems.ntfs-3g.devel/447
Regards,
Szaka
On Wed, 12 Mar 2008, Barry Kelly wrote:
> 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/
>
--
NTFS-3G: http://ntfs-3g.org
-------------------------------------------------------------------------
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
