bz2 question...

[TheBigAmbulance]

Let's say I am working with a file that was originally 136 GB. Then for reason X (mv, cp, something), the file size is now 7 GB. When I run the verify/test as 'bzip2 -tv file.bz2', it states that there is a premature end of the archive file. which in my mind was a mv or something in that light.

Is there a recovery record native in bz2 files? Is there any way to recover it (I'm thinking no)? The data is not able to be replicated at all. So if this file is gone, it's gone. So I'm grasping for straws. I have done a 'photorec' of the drive already, and there is not a bz2 file of 136 GB. This also points to a mv gone wrong.

Should I just prepare to flog my learning systemsadmin?

[Snowhog]

Sounds like you did a cp or mv from one drive to another removable drive and disconnected the drive before the write action had actually completed. IF that is the case, the resulting .bz2 file is toast. You can't recover what isn't there.

[TheBigAmbulance]

Thanks Snowhog!

I didn't think there was a way. I was teaching a coworker how to image systems/disks with clonezilla. Left them alone for a day or two, an they were then doing something and working with a disk when I was informed and heard "is it bad when".

Oh well, I will try and run gpart and other utilities to see if I can restore the partition table. Problem is, I think that it's been repartitioned several times since. So it's probably GOOD and mixed up.

[jlittle]

Maybe this isn't helpful, but a bz2 of 136 GB implies a larger original, typically 5 or 10 times larger, which seems far too big for most systems... I suspect the original file was 136 GB so someone thought they'd use bzip2 to compress it, which would take a long time, hours maybe, and they didn't let it finish, or ran out of space.

Anyway, there exists the bzip2recover utility, might be worth a shot.

Regards, John Little

[SteveRiley]

Sounds like you did a cp or mv from one drive to another removable drive and disconnected the drive before the write action had actually completed.

Many filesystems in Linux implement asynchronous writes. That is, control is returned to the user (or program) before the write is completely flushed from memory buffers to disk. It's important to keep this in mind with working with removable drives.

You can flush all writes at the command line:

sync

The cursor will jump to the next line and stay there until the flush operation completes; after that, the command prompt is displayed. Now it's safe to unplug the drive. Perhaps a good habit to acquire if you like to spend time at the command line.

[life0riley]

Many filesystems in Linux implement asynchronous writes. That is, control is returned to the user (or program) before the write is completely flushed from memory buffers to disk. It's important to keep this in mind with working with removable drives.

You can flush all writes at the command line:

sync

The cursor will jump to the next line and stay there until the flush operation completes; after that, the command prompt is displayed. Now it's safe to unplug the drive. Perhaps a good habit to acquire if you like to spend time at the command line.

Thanks for that. I had always assumed it was done when I got the command prompt back ($) after I issued a copy command.