Hi, Richard W.M. Jones wrote: > On Tue, Jan 26, 2016 at 08:54:27AM +0000, Richard W.M. Jones wrote: >> On Tue, Jan 26, 2016 at 08:37:48AM +0100, Jean-Pierre André wrote: >>> Jean-Pierre André wrote: >>>> Richard W.M. Jones wrote: >>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1301593#c6 >>> >>> After reading the original report, I do not think the error >>> is caused by the use of an illegal Unicode point. File names >>> like "Chaînes" are perfectly valid... provided that an utf8 >>> locale is used. >>> >>> Also, when hexediting a file name you may change the collating >>> sequence leading to failures in directory index searches. >>> If you need to hexedit, use chkdsk to fix the directory >>> indexes. >> >> To be clear, I'm only using hexedit in an attempt to recreate the bug >> report on my local machine. The directory in my test only has a >> single entry, so I didn't think that collation would be affected. >> >>> Can you get an image of the original partition, restricted >>> to metadata, hopefully leading to a manageable size ? >>> >>> ntfsclone -mst -O - /dev/something | gzip > metadata.gz >> >> I'm going to ask the user to try to get this. > > Finally I've managed to obtain this from the reporter. It's rather > large (29MB xz-compressed) and possibly contains sensitive data.
As this is metadata only, there is no user contents and the unused parts of metadata clusters have been wiped out. However the file names are present and they may be sensitive,... but the bug hunt is about a file name. > > Does Tuxera / ntfs-3g have a way to share sensitive disk images with > developers only? Tuxera must have ways to access and store sensitive customer data, but I personally do not share data with Tuxera. > I booted up a VM with a virtual disk and restored the image, and that > seemed to go OK: > > # ntfsclone -r -O /dev/sda1 /tmp/clone/ntfsclone_sda2 You could have avoided storing an uncompressed image : gzip -cd metadata.gz | ntfsclone -r -O /dev/sda1 - > ntfsclone v2015.3.14 (libntfs-3g) > Ntfsclone image version: 10.1 > Cluster size : 512 bytes > Image volume size : 41940702208 bytes (41941 MB) > Image device size : 41940702720 bytes > Space in use : 1147 MB (2.7%) > Offset to image data : 56 (0x38) bytes > Restoring NTFS from image ... > Syncing ...ent completed > > I was able to mount the disk, and reproduce the reported error: > > # mount /dev/sda1 /sysroot/ > # ls /sysroot/WINDOWS/system32/ > ls: reading directory /sysroot/WINDOWS/system32/: Invalid or incomplete > multibyte or wide character > > So that is encouraging, in that the bug can be reproduced starting > from the reporter's disk. > > What would help here? Enabling debugging in ntfs-3g perhaps? I do not think there is any useful predefined trace which would help, so enabling debugging is unlikely to be of much help. Most likely there is an invalid file name which has to be fixed by replacing invalid characters by valid ones. However this will change the collation sequence of file names in directories and could lead to create problems accessing files. There are several ways to tackle this issue, but before doing anything, it would be useful to define what is needed : just identifying which files are bad (and recover them from some archive), recovering a few files, etc. The issue is in a Windows system directory, so there is probably nothing user related there. Another parameter is the time you are willing to spend on this. I probably have tools which I can send to you personally if the customer does not want me to get the image. A few ideas : - identify the inode number of bad files and extract the contents by using ntfscat - patch the file names on disk and run chkdsk to adjust directories. - hack the Unicode to utf8 translation so that the invalid characters do not block (the translation has to be done both ways for processing directories). By the way, please check the $UpCase file : md5sum 'sysroot/$UpCase' (quoted needed for the $), you should get one of : 6fa3db2468275286210751e869d36373 2f03b5a69d486ff3864cecbd07f24440 7ff498a44e45e77374cc7c962b1b92f2 Regards Jean-Pierre ------------------------------------------------------------------------------ _______________________________________________ ntfs-3g-devel mailing list ntfs-3g-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
