Hi, I have been able to fix the NTFS image I have been allowed to download.
Richard W.M. Jones wrote: > On Wed, Apr 06, 2016 at 12:17:48PM +0200, Jean-Pierre André wrote: >> 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. > There are four bad file names in the system32 directory, they have a similar name with a bad surrogate pair followed by ".log". A fifth one has a similar name, but it has a valid surrogate pair. They are small files (108 or 132 bytes) created at different dates. One of them is recent, maybe the customer can remember something specific being started on Monday (mornings in the US). Here are the creation dates : Thu Feb 18 10:47:30 2016 UTC Mon Aug 18 14:08:27 2014 UTC Mon Oct 5 13:25:12 2015 UTC Mon Jun 4 11:43:29 2012 UTC Mon Aug 18 14:02:22 2014 UTC > The problem is not really with this particular image. It's not that > we need to recover files from it or anything like that. The problems > are: > > - How did this situation arise in the first place? As I said surrogate pairs are present, which make them unlikely to have been created by Windows XP. The pairs are : da5c dc93 (this is the valid one) dc5c dc93 dd5c dc93 de24 dc93 de5c dc93 I have been able to replace them with valid characters, and I can provide the disk patches if the customer wants to get a clean image. > - Could it happen again for other Windows guests. As (bad) surrogate pairs are present in a Windows XP image, and these files have no short names, I am inclined to think ntfs-3g has something to do with it. There has been no change in utf8 to utf16 translations for six years, and I am not aware of any other bug report related to the translations. More examination needed for telling what has happened. > Plus, it'd be nice if ntfs-3g could ignore (or at least not give a > hard error) in these cases. It's actually the getdents(2) system call > which fails, so any access at all to the directory returns -EILSEQ. This will mean (optional) cheating with the translations so that bad Unicode characters can translate to utf8 and back to bad Unicode. > We were trying to read a few files from \Windows\System32, it's most > likely that the "corrupt" file is not a file that we care about. I can provide disk patches if you want to delete them. Regards Jean-Pierre ------------------------------------------------------------------------------ _______________________________________________ ntfs-3g-devel mailing list ntfs-3g-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
