Gil Barash via ntfs-3g-devel wrote:
Hey,
I have two follow up issues:
--- 1 ---
When trying to run the patched version on
"ntfs_poweroff_fullLogs.partition.raw" (provided earlier) all I get
is:
Capacity 533724672 bytes (533 MB)
sectors 1042431 (0xfe7ff), sector size 512
clusters 130303 (0x1fcff), cluster size 4096 (12 bits)
MFT at cluster 43434 (0xa9aa), entry size 1024
4 MFT entries per cluster
* Using initial restart page, syncing from 0xd2170fb, dirty
* Block size 4096 bytes
The command I use is "ntfsrecover
ntfs_poweroff_fullLogs.partition.raw" (trying to use -f or -b gives
the same result). Can you assist please?
This is what I get from the image you posted earlier.
Apparently the initial syncing point is not the same
(I get 0x237146)
[linux@dimension]$ ntfsprogs/ntfsrecover barash2.ntfs
** Fast restart mode detected, data could be lost
Use option --kill-fast-restart to bypass
[linux@dimension]$ ntfsprogs/ntfsrecover -sk barash2.ntfs
* Syncing successful after playing 3881 actions
[linux@dimension]$ ntfsprogs/ntfsrecover -vsk barash2.ntfs
Capacity 533724672 bytes (533 MB)
sectors 1042431 (0xfe7ff), sector size 512
clusters 130303 (0x1fcff), cluster size 4096 (12 bits)
MFT at cluster 43434 (0xa9aa), entry size 1024
4 MFT entries per cluster
* Using initial restart page, syncing from 0x237146, dirty
* Block size 4096 bytes
[approx 175100 lines deleted]
* Syncing successful after playing 3881 actions
Redo actions which were executed :
Noop
CompensationlogRecord
InitializeFileRecordSegment
DeallocateFileRecordSegment
CreateAttribute
DeleteAttribute
UpdateResidentValue
UpdateMappingPairs
SetNewAttributeSizes
AddIndexEntryAllocation
DeleteIndexEntryAllocation
UpdateFileNameAllocation
SetBitsInNonResidentBitMap
ClearBitsInNonResidentBitMap
ForgetTransaction
OpenAttributeTableDump
AttributeNamesDump
DirtyPageTableDump
[starting chkdsk.exe from Windows 10]
The type of the file system is NTFS.
Volume label is New Volume.
Stage 1: Examining basic file system structure ...
256 file records processed.
File verification completed.
0 large file records processed.
0 bad file records processed.
Stage 2: Examining file name linkage ...
282 index entries processed.
Index verification completed.
0 unindexed files scanned.
0 unindexed files recovered to lost and found.
Stage 3: Examining security descriptors ...
Security descriptor verification completed.
13 data files processed.
Windows has scanned the file system and found no problems.
No further action is required.
521215 KB total disk space.
55724 KB in 55 files.
20 KB in 15 indexes.
0 KB in bad sectors.
5339 KB in use by the system.
460132 KB available on disk.
4096 bytes in each allocation unit.
130303 total allocation units on disk.
115033 allocation units available on disk.
[linux@dimension]$
I get the same result on 32-bit and 64-bit CPUs and
on little endian and big endian ones.
I have made minor changes since I posted a patch, but
they should not be much relevant (the posted patch ran
successfully).
Maybe you get the latest (full) state from
https://sourceforge.net/p/ntfs-3g/ntfs-3g/ci/edge/tree/
Or you apply to the latest release ntfs-3g-2017.3.23
the following couple of patches :
https://sourceforge.net/p/ntfs-3g/ntfs-3g/ci/1797ab5ecd5a544f34c83a9c7efabd0c33e3c954/
and
https://sourceforge.net/p/ntfs-3g/ntfs-3g/ci/5be0b9f62a7eabddbac3119a12b98cc1b4c233d4/
I am sure that I have successfully applied the patch and that I am
using the patched version.
--- 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.
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
On Mon, May 22, 2017 at 11:47 AM, Gil Barash <gil.bar...@zerto.com> wrote:
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
------------------------------------------------------------------------------
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
