Hi, It appears that the latest log records are stored very differently in logfile 2.0 (which is the format used by Windows 8 and Windows 10 when the fast restart mode is activated).
I have prepared an upgrade to support the new format. The metadata of both your partition images can now be repaired. These are the only partitions which I have checked so far, so problems could still be experienced. The patch against the latest ntfs-3g (v 2017.3.23) is available at : http://jp-andre.pagesperso-orange.fr/logfile-2.0.patch.zip Jean-Pierre Jean-Pierre André wrote: > Gil Barash wrote: >> Hello Jean-Pierre, and thank you for the quick response. >> >> On Thu, May 11, 2017 at 7:38 PM, Jean-Pierre André >> <jean-pierre.an...@wanadoo.fr> wrote: >>> >>> Gil Barash wrote: >>>> Hello, >>>> >>>> I'm trying to use the ntfsrecover tool to recover the partition. >>>> I have a data disk (~500MB) on a Windows machine. I wrote to it some >>>> files while powering off the machine (pulling the cable). The resulting >>>> filesystem has some corrupt files - doing "ls" gives me stuff like: >>>> ? -????????? ? ? ? ? ? file_20K_24385 >>>> So, I tried to use the ntfsrecover tool in order to fix those file >>>> entries. However, it never succeed (I did this experiment a few times). >>>> >>>> Here, as an example, is the output of "./ntfsrecover -v >>>> --kill-fast-restart /mnt/data/ntfs_poweroff_fullLogs.partition.raw" (my >>>> "disk" is a file representing a partition): >>>> > > [...] > >> >> Indeed, I am using Windows 8 (Windows Server 2012R2). >> I don't mind deleting the hibernation file since I'm not going to boot >> from this disk - I just want to extract some files out of it. To the >> best of my understanding, the filesystem should be consistent without >> the hibernation file (i.e. everything written in the hibernation file >> is also written to, or can be extracted from, the filesystem itself). >> Also note that I tried mounting this disk (or actually, a copy of it) >> on a different Windows machine, as a data disk (so the hibernation >> file is not used), and Windows was able to show me a consistent list >> of files (all of the files were readable), which was a bit different >> from the one I got from ntfs-3g. > > I checked the consistency of the metadata could be restored > by Windows 10 (but not by Windows 7). > >>> >>> Locating the first record may also be buggy in ntfsrecover. >>> To investigate it, I need the first 16K bytes from the > > I can confirm ntfsrecover could not locate the first log > record (the oldest one which was committed while not > synced). > >>> log file : >>> dd if='/mntpnt/$LogFile' of=temp bs=4096 count=4 >>> (important : mount as readonly, replace mntpnt be the >>> actual mount point). >> >> Note that running "ntfsrecover -t --kill-fast-restart >> ntfs_poweroff_fullLogs.partition.raw" does seem to work, as a lot of >> entries are listed and the print does not end with any kind of error >> message (leading me to believe that the last entry printed is indeed >> the last valid entry). >> >> I hope I'm not causing any confusion, but I would like to share two >> disks which show different symptoms: >> --- 1 --- >> ntfsrecover --kill-fast-restart >> /mnt/data/ntfs_poweroff_fullLogs.partition.raw >> ** Bad first record at offset 0x288 >> ** Error : searchlikely() used for syncing >> * Syncing failed after playing 0 actions >> >> LogFIle: >> https://s3-eu-west-1.amazonaws.com/gilbucket1/ntfs-disks/ntfs_poweroff_fullLogs.LogFile >> Entire partition: >> https://s3-eu-west-1.amazonaws.com/gilbucket1/ntfs-disks/ntfs_poweroff_fullLogs.partition.raw >> >> --- 2 --- >> ntfsrecover --kill-fast-restart /mnt/data/ntfs_poweroff_2.raw >> * Reaching free space at end of block 2 >> * Syncing failed after playing 0 actions >> >> LogFile: >> https://s3-eu-west-1.amazonaws.com/gilbucket1/ntfs-disks/ntntfs_poweroff_2.LogFile >> Entire partition: >> https://s3-eu-west-1.amazonaws.com/gilbucket1/ntfs-disks/ntfs_poweroff_2.raw.bak >> > > You were using this partition with the fast restart mode > activated, which implies a different log format (2.0), see > https://social.technet.microsoft.com/wiki/contents/articles/15645.windows-8-volume-compatibility-considerations-with-prior-versions-of-windows.aspx > > I have not yet decoded the format changes, so recovering from a > partition used with fast restart mode activated will generally > fail if there are unsynced committed changes. > > Users who want to share data between Windows 8+ and Linux > should disable the fast restart mode. > > Jean-Pierre > >> Gil >> >>> >>> Jean-Pierre >>> >>>> >>>> Thanks, >>>> Gil ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ ntfs-3g-devel mailing list ntfs-3g-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
