Hey, I was surprised to learn, by your previous comment, that the journal format has changed.
It is great to hear that you were able to create a patch to support this new format. I will probably check the ntfsrecover tool (with the patch) in several scenarios (using Windows 7, 8 & 10), and compare the "fixed" filesystem against the one "fixed" by windows itself (excluding the hibernation file, of course). I'll be sure to inform you if any other problem arise. Thanks, Gil On Mon, May 22, 2017 at 11:22 AM, Jean-Pierre André <jean-pierre.an...@wanadoo.fr> wrote: > 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 ------------------------------------------------------------------------------ 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
