bin/142155: dumpfs(8) drops leading 0 (zero) from superblock id

[Efstratios Karatzas]

The following reply was made to PR bin/142155; it has been noted by GNATS.

From: Efstratios Karatzas <gpf.kira at gmail.com>
To: bug-followup at FreeBSD.org, tigger at lvlworld.com
Cc:  
Subject: Re: bin/142155: dumpfs(8) drops leading 0 (zero) from superblock id
Date: Mon, 4 Jan 2010 17:51:17 +0200

 --0016e6d9a0e81b15e7047c58b1cd
 Content-Type: text/plain; charset=ISO-8859-1
 
 Hi.
 
 Not sure if this qualifies as a bug, but it's certainly a little
 misleading if you want to manipulate ufsids.
 The only issue here is that ufsid is the result of concatenating two
 fs ids, in your example the hex numbers "4ae2d4ec" and "6f7fec5"
 Each id number has a max length of 8 digits so when concatenating the
 two ids to create the ufsid, a 0 is added in front of "6f7fec5" to
 maintain a length of 16 characters total and actually keep the
 original numbers in the ufsid. Two possible fixes:
 
 1) Change the way you interpret the output of dumpfs(8) in a way
 similar to the one described in the following link
 
 http://www.mail-archive.com/freebsd-stable@freebsd.org/msg106566.html
 
 Notice the "printf %0x $((0x\1 << 32 | 0x\2))/p" part, simple bitwise operations
 
 2) Apply my patch and recompile dumpfs so that if one of the ids has
 fewer than 8 digits, leading zeros are always printed. That way your
 script doesn't have to do anything "special"
 
 Elaboration:
 
 In dumpfs.c, line 153
 
 printf("superblock location\t%jd\tid\t[ %x %x ]\n",
 (intmax_t)afs.fs_sblockloc, afs.fs_id[0], afs.fs_id[1]);
 
 You can see it's printing two variables in hex (%x = unsigned hex number)
 The fs_id array is of type int32_t so the maximum value has 8 digits.
 
 Hope this helps, reply if somehow you still have a problem.
 
 -- 
 
 Efstratios "GPF" Karatzas
 
 --0016e6d9a0e81b15e7047c58b1cd
 Content-Type: application/octet-stream; name="dumpfs_patch.diff"
 Content-Disposition: attachment; filename="dumpfs_patch.diff"
 Content-Transfer-Encoding: base64
 X-Attachment-Id: f_g41fb7k30
 
 KioqIGR1bXBmcy5vcmlnLmMJTW9uIEphbiAgNCAxNzowNToxNCAyMDEwCi0tLSBkdW1wZnMuYwlN
 b24gSmFuICA0IDE3OjA3OjA1IDIwMTAKKioqKioqKioqKioqKioqCioqKiAxNTAsMTU2ICoqKioK
 ICAJCWZzdGltZSA9IGFmcy5mc190aW1lOwogIAkJcHJpbnRmKCJtYWdpY1x0JXggKFVGUzIpXHR0
 aW1lXHQlcyIsCiAgCQkgICAgYWZzLmZzX21hZ2ljLCBjdGltZSgmZnN0aW1lKSk7CiEgCQlwcmlu
 dGYoInN1cGVyYmxvY2sgbG9jYXRpb25cdCVqZFx0aWRcdFsgJXggJXggXVxuIiwKICAJCSAgICAo
 aW50bWF4X3QpYWZzLmZzX3NibG9ja2xvYywgYWZzLmZzX2lkWzBdLCBhZnMuZnNfaWRbMV0pOwog
 IAkJcHJpbnRmKCJuY2dcdCVkXHRzaXplXHQlamRcdGJsb2Nrc1x0JWpkXG4iLAogIAkJICAgIGFm
 cy5mc19uY2csIChpbnRtYXhfdClmc3NpemUsIChpbnRtYXhfdClhZnMuZnNfZHNpemUpOwotLS0g
 MTUwLDE1NiAtLS0tCiAgCQlmc3RpbWUgPSBhZnMuZnNfdGltZTsKICAJCXByaW50ZigibWFnaWNc
 dCV4IChVRlMyKVx0dGltZVx0JXMiLAogIAkJICAgIGFmcy5mc19tYWdpYywgY3RpbWUoJmZzdGlt
 ZSkpOwohIAkJcHJpbnRmKCJzdXBlcmJsb2NrIGxvY2F0aW9uXHQlamRcdGlkXHRbICUwOHggJTA4
 eCBdXG4iLAogIAkJICAgIChpbnRtYXhfdClhZnMuZnNfc2Jsb2NrbG9jLCBhZnMuZnNfaWRbMF0s
 IGFmcy5mc19pZFsxXSk7CiAgCQlwcmludGYoIm5jZ1x0JWRcdHNpemVcdCVqZFx0YmxvY2tzXHQl
 amRcbiIsCiAgCQkgICAgYWZzLmZzX25jZywgKGludG1heF90KWZzc2l6ZSwgKGludG1heF90KWFm
 cy5mc19kc2l6ZSk7Cg==
 --0016e6d9a0e81b15e7047c58b1cd--