Hi again, I would like to add : - My Windows encoding is cp1252 - The collation sequences in Windows and Linux are not the same, do not compare the files by position in the listing.
To do it again at Win32 level, should I use the single byte encoding or the wide char encoding ? Regards Jean-Pierre Jean-Pierre André wrote: > Hi > > Attached is my report, I zipped it to make sure character encoding > is kept unchanged. > > In short I could not create files with the following chars : > 0x01-0x1f > 0x22 (should be escaped ?) > 0x2a * > 0x3a : > 0x3c < > 0x3e > > 0x3f ? > 0x5c \ > 0x7c > File creation was done through a run time library which > may have done its own checking. I will retry with direct > use of Win32 API unless somebody else does it. > > Then chkdsk found no error. > > Regards > > Jean-Pierre > > > > > Szabolcs Szakacsits wrote: >> 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 >> >> >> > -- JP André email [EMAIL PROTECTED] ------------------------------------------------------------------------- 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
