Cat command details

The cat command prints to stdout a file or the entire snapshot content if no file is specified.

Click here for a list of related forum topics.

Quick overview

NAME:
   duplicacy cat - Print to stdout the specified file, or the snapshot content if no file is specified

USAGE:
   duplicacy cat [command options] [<file>]

OPTIONS:
   -id <snapshot id>            retrieve from the snapshot with the specified id
   -r <revision>                the revision number of the snapshot
   -storage <storage name>      retrieve the file from the specified storage
   -key <private key>           the RSA private key to decrypt file chunks
   -key-passphrase <passphrase> the passphrase to decrypt the RSA private key

Usage

duplicacy cat [command options] [<file>]

Options


-id <snapshot id>

You can specify a different snapshot id rather than the default id.


-r <revision>

By default the latest revision is selected.
If -r is specified, then that revision is selected instead.


-storage <storage name>

You can use the -storage option to select a different storage other than the default one.


-key <private key> and -key-passphrase <passphrase>

If the storage is encrypted by an RSA public key, the corresponding private key is needed to print out the content of any file.

Notes

The file must be specified with a path relative to the repository.

duplicacy cat outputs one extra preliminary line to stdout, making it impossible to just pipe the output to a file for a simple restore operation. I discovered this when using duplicacy cat on a png file today.

The line looks like this

Repository set to …

VERSION:
2.3.0 (504D07)

As a workaround, I use an intermediate pipe to

awk 'NR>1'
2 Likes

there must be some other issue as well with “cat”

when I restore a 4 GiB file via “restore” command the file is valid

however when I restore same file via “cat” command the file is corrupt, the first changes are visible right after 1008 GiB (used cmp -l to diff them)

maybe “cat” does not work for large files? there is some buffer/cache issue in such case?

i faced this issue when restoring ext4 lvm2 fs from backup that was split into 4 GiB parts via chunkfs before processing by duplicacy - I simply tried to cat the 4 GiB files from backup and dd to the block device but the result was a corrupt ext4 fs (block device was a lvm2 lv)

now I tried first to restore the 4 GiB files and used unchunkfs to construct an image file from the 4 GiB parts and copied the image content to the block device using dd - the result seems OK after running e2fschk

so the issue is with duplicacy cat somehow, but I cannot figure out the reason due to the large file size