Recording for Mirages: Sabine Devieilhe - French Opera Arias.
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
The purpose of BlockHashLoc is to enable the recovery of files after total loss of File System structure, or without even knowing what FS was used in the first place.
The way it can recover a given file is by keeping a (small) parallel BHL file with a list of crypto-hashes of all the blocks (of selectable size) that compose it. So it's then possible to read blocks from a disk image/volume, calculate their hashes, compare them with the saved ones and rebuild the original file.
With adequately sized blocks (512 bytes, 4KB, etc. depending on the media and File System), this let one recover a file regardless of the FS used, or the FS integrity, or the fragmentation level.
This project is related to SeqBox. The main differences are:
- SeqBox create a stand-alone file container with the above listed recovery characteristics.
- BHL realize the same effect with a (small) parallel file, that can be stored separately (in other media, or in the cloud), or along the original as a SeqBox file (so that it can be recovered too, as the first step), so it can be used to add a degree of recoverability to existing files.
@Mark0: Thanks. The version 3 is necessary only because that is the version my daughter is being taught with at school.-IainB (April 06, 2017, 05:25 PM)
but this really does sound like something everyone SHOULD be using-solaris65 (April 05, 2017, 06:51 AM)
Seqbox recoverability have been practically tested with a number of File Systems. The procedure involved using a Virtual Machine to format a small (about 100MB) disk image with a certain FS, filling it with a number of small files, then deleting some randomly to free enough space to copy a serie of SBX files. This way every SBX file results fragmented in a lot of smaller pieces. Then the image was quick-formatted, wipefs-ed and the VM shutdown.
After that, from the host OS, recovery of the SBX files was attempted using SBXScan & SBXReco on the disk image.
- Working: BeFS, BTRFS, EXT2/3/4, FATnn/VFAT/exFAT, AFFS, HFS+, JFS, MINIX FS, NTFS, ProDOS, ReiserFS, XFS, ZFS.
- Not working: OFS (due to 488 bytes blocks)
Being written in Python 3, SeqBox tools are naturally multi-platform and have been tested successfully on various versions of Windows, on some Linux distros either on x86 or ARM, and on Android (via QPython). No test was done on OS X but it should works there as well (feedback welcome).
Pretty nightmarish! Now on to SBXScan to search for pieces of SBX files around, and SBXReco to get a report of the collected data:
A SeqBox container have a blocksize sub/equal to that of a sector, so can survive any level of fragmentation. Each block have a minimal header that include a unique file identifier, block sequence number, checksum, version. Additional, non critical info/metadata are contained in block 0 (like name, file size, crypto-hash, other attributes, etc.).
If disaster strikes, recovery can be performed simply scanning a volume/image, reading sector sized slices and checking blocks signatures and then CRCs to detect valid SBX blocks. Then the blocks can be grouped by UIDs, sorted by sequence number and reassembled to form the original SeqBox containers.