From: Phillip S. <ph...@th...> - 2019-04-05 20:40:18
|
On 4/5/2019 3:09 PM, Phillip Susi wrote: > So the problem seems to be not specific to rmt, but to compressed tape > backups. Even if you are using a normal file via rmt, dump treats it > like a tape and calls readtape_comprtape instead of readtape_comprfile. > The latter reads the first 4 byte header of the block first to decide > how long the block actually is on disk, then reads that many bytes. The > latter reads a fixed length of the uncompressed block size + the 4 byte > header, which causes it to consume far more than a single block and so > when it goes to read the header for the next block, it's actually > reading some random data from the wrong location in the file. Fixed it. Attaching patch. I got rid of the separate readtape_comptape function and merged the two into one function that handles compressed backups properly. |