1

If there is a Linux.img file, I can see the actual size of the image. if there is a Linux.img.xz file, how can I tell the size of it when xz = Popen(["/usr/bin/xz", "-cdk", "Linux.img.xz"], stdout=PIPE) is executed. The decompressed file is written to the standard output, there will not be an actual file on the disk that I can check with command fdisk -l <FILE>.

Why I am doing this is because the image is about to be written to a SD card. Right before that I want to check if the image is larger than the SD card. Using the stdin and stdout can avoid disk writing which can speed up the process a little bit.

Jason Liu
  • 749
  • 4
  • 16
  • 34
  • 1
    Related: https://stackoverflow.com/questions/1815329/portable-way-to-get-file-size-in-bytes-in-shell – Morrison Chang Jun 01 '18 at 21:14
  • 1
    @Morrison, I don't see any similarity with that question. The image contains partition information, the actual size is different that the file size. I want to know how to get the actual size from the decompressed file in the stdout. – Jason Liu Jun 01 '18 at 21:17
  • If you're writing this image to the sd card, why do you care about partition information rather than image file size? Are you dealing with images with dead space that you're happy to truncate? If so, why? – that other guy Jun 01 '18 at 21:20
  • @that other guy, I use `dd` command to write the image to a SD card, which will fully copy the image including all partitions (hidden partition with exact size), and files in each partitions. If the SD card is sufficient, there will be file corruption and the system will not be able to boot. – Jason Liu Jun 01 '18 at 21:22
  • 1
    Now i'm confused as OP is using `dd`: https://serverfault.com/q/95639/299610 and could just expanded data first to /dev/null to get count – Morrison Chang Jun 01 '18 at 21:24
  • @Morrison, Thanks, that could work, but I think expanding data to other places it not that great only for the checking. My most concern is the efficiency because a system image could be large. However if there is no way to count the size in the standard output, this is the solution. – Jason Liu Jun 01 '18 at 21:30
  • 1
    @JasonLiu In that case `fdisk -l` should not have any part in the solution. You just need to know the uncompressed size. `xz` does store this in the header when it's known, though you can have completely valid xz files without a correct size (due to streaming compression or concatenation). Depending on how robust and general you need it to be, you could simply decode it from the header and ignore cases where it's wrong. – that other guy Jun 01 '18 at 21:37
  • @that other guy I think you are right, I am sorry that my previous comment is totally wrong . The `.img` file seems does not have any kind of compression, its only on `.xz`. And your answer seems correct to me, I just need to extract the header to get the size. Could you make it as the answer so that I can highlight you as the solution. Thank you. – Jason Liu Jun 01 '18 at 21:45
  • In this case, the command `xz -l ` is the best approach to compare the size before it gets decompressed. – Jason Liu Jun 01 '18 at 21:58
  • I'm sure future readers would love a copy-pastable solution. If you're already writing one with the `lzma` library or by parsing `xz -l` output, just post that in an easily reusable form and I'll upvote it ^^ – that other guy Jun 01 '18 at 22:09

1 Answers1

0

Since the system image file is not compressed. Turns out the question becomes how to get the uncompressed size of the compressed image.

One way to check is to use the command xz -l. This should return the all information about the compressed file including uncompressed size. The answer is inspired by that other guy.

Jason Liu
  • 749
  • 4
  • 16
  • 34