in reply to unpack'ing "64-bit quantities"

Probing a ntfs-3g mounted volume, the CLI command getfattr -n system.ntfs_times file gives me:

system.ntfs_times=0sUMKxfHwEyQFMaayBfwTJAXa37TWB98oB7hGD3t6jyQE=

and according to man the leading 0s indicates it is base64 encoded. Likewise getfattr -e hex -n system.ntfs_times file gives hex output:

system.ntfs_times=0x50c2b17c7c04c9014c69ac817f04c90176b7ed3581f7ca01ee1183dedea3c901

And from there, even your verbose comments, do not help me much. I've used unpack() in the past but more in trial and error... How am I supposed to extract 4 epoch values from this string?

Replies are listed 'Best First'.
Re^2: unpack'ing "64-bit quantities"
by BrowserUk (Patriarch) on Jun 21, 2010 at 12:53 UTC

    Less verbose:

    #! perl -slw use strict; use constant { MSEpoch_2_UnixEpoch => 116444736000000000, ## corrected }; my $in = '0x50c2b17c7c04c9014c69ac817f04c90176b7ed3581f7ca01ee1183dede +a3c901'; my @hexTimes = unpack 'xx(A16)4', $in; my @binTimes = map{ unpack 'Q', pack 'H16', $_ } @hexTimes; my @unixTimes = map{ ( $_ - MSEpoch_2_UnixEpoch ) /1e7 } @binTimes; print scalar localtime( $_ ) for @unixTimes; __END__ [13:52:05.69]C:\test>845551.pl Fri Aug 22 17:28:27 2008 Fri Aug 22 17:50:03 2008 Wed May 19 18:29:26 2010 Fri Mar 13 13:23:16 2009

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
      MSEpoch_2_UnixEpoch => 116444700000000000, ## Corrected (I think)

      Not entirely sure, but I think it should be

      116444736000000000 == (int( (1970 - 1601) * 365.25 ) - 3) * 24 * 60 * +60 * 1e7

      (your magic value seems to be one hour off)

        (your magic value seems to be one hour off)

        Indeed. I forgot to correct for BST. (Now done.)

      Of course, "verbose" (copious) was meant in a positive way!

      Thanks again...