1 |
On Mon, Feb 21, 2022 at 8:29 PM Grant Edwards<grant.b.edwards@×××××.com> wrote: |
2 |
|
3 |
> I've got a "raw" USB flash drive containing a large chunk of gzipped |
4 |
> data. By "raw" I mean no partition table, now filesystem. Think of it |
5 |
> as a tape (if you're old enough). |
6 |
> |
7 |
> gzip -tv is quite happy to validate the data and says it's OK, though |
8 |
> it says it ignored extra bytes after the end of the "file". |
9 |
> |
10 |
> The flash drive size is 128GB, but the gzipped data is only maybe |
11 |
> 20-30GB. |
12 |
> |
13 |
> Question: is there a simple way to copy just the 'gzip' data from the |
14 |
> drive without copying the extra bytes after the end of the 'gzip' |
15 |
> data? |
16 |
> |
17 |
> The only thing I can think of is: |
18 |
> |
19 |
> $ zcat /dev/sdX | gzip -c > data.gz |
20 |
> |
21 |
> But I was trying to figure out a way to do it without uncompressing |
22 |
> and recompressing the data. I had hoped that the gzip header would |
23 |
> contain a "length" field (so I would know how many bytes to copy using |
24 |
> dd), but it does not. Apparently, the only way to find the end of the |
25 |
> compressed data is to parse it using the proper algorithm (deflate, in |
26 |
> this case). |
27 |
> |
28 |
> -- |
29 |
> Grant |
30 |
|
31 |
Hi Grant, |
32 |
|
33 |
you could use gzip to tell you the compressed size of the file and then |
34 |
use another method to copy just those bytes (dd for example): |
35 |
|
36 |
gzip -clt </dev/sdX |
37 |
|
38 |
Should print the compressed size in bytes, although by reading through |
39 |
the entire stream once. |
40 |
|
41 |
-- |
42 |
Felix |