Re: Extracting with sequential read, isolated catalogue and no tape marks
Denis Corbin <[email protected]> Fri, 20 Dec 2024 21:53:35 +0100
| Newsgroups | gmane.comp.sysutils.backup.dar.support |
|---|---|
| Message-ID | <[email protected]> |
On 20/12/2024 18:45, [email protected] wrote: > Hello. Hello, > > I have a DAR archive created with no tape marks and an isolated > catalogue for it. I would like to extract it using sequential read, > which would allow for on-the-fly unpacking when downloading slices > sequentially — without it, I would have to download the last part first, > which I would like to avoid. From what I understand, lack of tape marks > should not impede unpacking when the isolated catalogue is provided. This is a wrong assumption: A backup without tape marks cannot be read with --sequential-read option. The reason is due to the fact this option inserts a tape layer between the slice layer and the compression layer, which role is to un-escape read data: tape mark use a specific byte sequence and to avoid saved data containing this same sequence to be considered as a tape mark, they are 'escaped' (I mean modified) to be recognized as data and not as tape mark at reading time. But if the archive has been created with -at option (thus without tape mark), data has not been modified to avoid collision with tape marks as there was no tape marks used in that archive. This is the reason of the "corruption" reported by dar. The restoration of such archive must not use --sequential-read, the origin of the catalog (internal or isolated). Thus even if the restoration is sequential with an external catalog, I mean it reads sequentially from the first slice to the last slice and in each slice also reads in growing byte order, to access a given data, dar/libdar makes a call to lseek() for the next read() operation to fetch the expected data, lseek() is not possible on a pipe only on plain files. By comparison, with --sequential-read option, in addition to un-escape read data, dar/libdar only call the read() system call and looks in the byte flow for tape mark to know what is coming next (directory/file/data/CRC/EA/FSA and so on), this leads to the construction of the catalogue during the whole process of the restoration (tape mark lead to add an "in-lined" catalog interleaved with the saved data). > Indeed, the extraction works, but it seems that the files extracted from > the slice number 1 are corrupted. Can you try using external catalog without --sequential-read option? This should solve the reported corruption and if you provide slices as files (not from a pipe) in the order they are requested, which should be from slice 1 to the last, you should be good. > > In other words: when I have all the slices present on disk already, > `dar -x archive -A isolated --sequential-read` > results in > `Error while restoring {file}: Bad CRC, data corruption occurred` > for the files contained in the first slice. After that first slice, > extraction continues normally without further errors. IMHO, this is not relative to slice 1, but to the nature of the data in your file, probably a dar archive with tape mark and without encryption is present in slice 1. > Regards, Denis
OpenPGP_signature.asc
(application/pgp-signature, 840 B)
-----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEVeSEpqXFvH9T9/cuqLFBYNNrO6cFAmdl2U8FAwAAAAAACgkQqLFBYNNrO6ff FQ//UZvmYy5GvF/svKZlwe+cqTw7/li7KgxdwCgn3j3XyO72RDIaPkj+073gNDcfY86BuOAVqzGO HyD1OTGShYwdyOUBi82b834XtopHKqq1LQsB7/lfHqT618PxYpd4oXMjJFg9zf9J0zelx4m5FjH0 Yf2oK9nGJlDOQu4GoXFaJ4AbatqjkItpBTJmugD3ZkgQzcfPR2BxQr1NOO+ntNpNbBeOA2ktL2tJ 1YojcWLRaefMpiRFI0iremUOhURoJGQl7jcnni4kG02ENIJAaTVurWlzhnnTIFIb3Jzhi5G2eV4d o/0MhC50FYXN8D9bSM+nIuUHWSdY95DcBUtGMQyTY4+nxYSN2NjNFrHC6KsvnVREIOuMoLnc2oX6 NWjkoHrDeuSYO8eGhTjziM46ncV8KwQN5iqLuchqkO1/8DFbI4I2FXAuX1+Vvrqccbh4FHLnp5vp xtJkqBTgNPTNQaHr+UNziphOdh0v9+YomY+ZgdtXAmCF5/12TScGLVP44+eqeHOQGb7WP5YiIjI8 KvbVh2JyCHxDmVFVjYX2nymQpBzX7ta58hTJdxAaN9DGBFGFaNmU7oOScy2sIG7Tzxt4ei80FwjX ZLKWvZk2XtBqz/8GLB4V5ZdVKug8FBcKFxlLsd7I+MMtM5bhtUJb4TWiaSaQpgwLXBzLcWI2utJa Ers= =Rx2s -----END PGP SIGNATURE-----