Hey, Downloading the latest did the trick. Thanks.
I agree that the data replacement operations are easier, but the bigger problems are when an attribute is added/deleted, because those operations shift the data for the following redo operations. I would love to hear the rational behind all this, extremely complicated, journal scheme from Microsoft, but that would probably never happen :-) I asked this because I am trying to debug a partition I created when crashing a Windows10 machine (you can find it here: https://s3-eu-west-1.amazonaws.com/gilbucket1/ntfs-disks/ntfs_shutdown_win10.raw). You can see that operation 239b94 fails the recovery process. The undo data of operation 239b94 is "0f" which differs from the "a0" found at 0x360. I think maybe the operation was targeting the "0f" at 0x3d8. Note that, an earlier operation, for the same inode (45), operation 229f2a (DeleteIndexEntryRoot) - is not executed because the undo data doesn't match. It has a length of 0x78 which is exactly 0x3d8-0x360 I tried to trace back, to see why operation 229f2a find the "wrong" data - perhaps an earlier operation also failed to run - but I didn't find anything definitive yet. Regards, Gil On Fri, Jun 16, 2017 at 10:59 AM, Jean-Pierre André <jean-pierre.an...@wanadoo.fr> wrote: > > Hi, > > Update... > > Jean-Pierre André wrote: >> >> Gil Barash via ntfs-3g-devel wrote: >> >>> Hey, >>> >>> I have two follow up issues: > > > [...] > >>> >>> --- 2 -- >>> General question about redo process: >>> In change_resident_expect (called by redo_update_root_vcn, for >>> example) we chose not to apply the redo data if the current buffer >>> state doesn't match the undo data. Note that the operation is >>> considered successful in this case. >> >> >> I think the reasoning is a follows : >> >> - the old state was A >> - an update is made, the state is now B >> - a second update is made, the state is now C >> - C is synced to disk, but a failure occurs before >> the syncing is recorded in the log. >> >> When restarting, both updates have to be replayed, >> and when applying the first one, the state on disk >> is not the undo state (which is A), so it is correct >> to apply the update (whose result will be overwritten >> by the second update). >> >> Avoiding the updates if the undo data does not match >> the state on disk probably leads to the same result, >> but IMHO it is safer to make sure the final state is >> what the redo data says. Other updates which overlap >> could be intertwined and they would be processed >> incorrectly when not applied to the same state as in >> the initial execution. > > > Well, actually the current code is doing the opposite > (that is applying the update if the current state matches > the undo data). > > I have run my tests again after reversing the rule (so > applying the update if the current state does not match > the redo data), and the tests fail when the second > update destroys the attribute (e.g. deleting a file). > In this situation there is nothing the redo data can > be compared against (more exactly the current state is > meaningless and should not be compared to redo data). > There is not enough information to rebuild the intermediate > state, the only possible action is doing nothing, and > some criterion is needed to go this way. > > Jean-Pierre > > >>> Can you please provide some small explanation or direct me to some >>> form of documentation as to why it is OK to skip an operation. >> >> >> I would also be interested to get some form of >> documentation... >> >> Regards >> >> Jean-Pierre >> >>> I suspect it might cause some kind of "chain-reaction" where future >>> operations on this "cluster" would also be skipped because they expect >>> to see the data as it should have been after applying the redo >>> operation. >>> >>> 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
