Compare tarballs with sha1sum

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;







up vote
2
down vote

favorite












I create a .tgz/tarball with $(npm pack).



I then run:



sha1sum oresoftware-npp-0.0.1001.tgz 


and I get:



77c58da68593dcdcd14bb16a37f5f63ef42bab63 oresoftware-npp-0.0.1001.tgz


I want to compare that shasum against another tarball on a remote server.
I can query for a shasum for a tarball on the NPM registry, with:



 npm view @oresoftware/npp@latest dist.shasum


which yields:



3c2e7328110ba57e530c9938708b35bde941c419


this shasum is different than the other one above, but that's expected, since I changed the contents of the .tgz tarball file.



my question is 3 fold:



  1. When I generated a sha1sum of the .tgz file resulting from npm pack, is that the right way to do it? To generate the sha1sum after the tar file is created?


  2. I assume that the the sha1sum would be identical if the tarballs had identical contents? Would they differ if the files were created/modified at different times even if they have otherwise the same contents?


  3. Is there a better way to check if two tarballs have the same contents? That's all I am trying to do.







share|improve this question





















  • A tar archive contains information about ownership and timestamps on files, so to compare two archives generated on two separate machines would likely not work. You would be better off extracting the content of the two archives and comparing that. I'm not writing an answer because I don't know, off the top of my head, of a simple way of doing that.
    – Kusalananda
    2 days ago










  • For comparing two archives, there is no software sulution. Since 25 years, star however supports to compare an archive with the filesystem and allows to configure what to compare while doing that.
    – schily
    2 days ago










  • @schily what about this: tar -xOzf foo.tgz | sort | sha1sum
    – Alexander Mills
    2 days ago











  • Since -O usually tells tar to create archives compatible to the 1977 format, you seem to seem to use a different program. Let me assume that you have GNU tar in mind. With that tar clone and that command, the content of the files is extracted to stdout. If you did omit sort, you would get a definite value to compare tar archives with the same order of files inside. With the sort call, the result does not help you as you could get the same final result even in case there are differences.
    – schily
    yesterday
















up vote
2
down vote

favorite












I create a .tgz/tarball with $(npm pack).



I then run:



sha1sum oresoftware-npp-0.0.1001.tgz 


and I get:



77c58da68593dcdcd14bb16a37f5f63ef42bab63 oresoftware-npp-0.0.1001.tgz


I want to compare that shasum against another tarball on a remote server.
I can query for a shasum for a tarball on the NPM registry, with:



 npm view @oresoftware/npp@latest dist.shasum


which yields:



3c2e7328110ba57e530c9938708b35bde941c419


this shasum is different than the other one above, but that's expected, since I changed the contents of the .tgz tarball file.



my question is 3 fold:



  1. When I generated a sha1sum of the .tgz file resulting from npm pack, is that the right way to do it? To generate the sha1sum after the tar file is created?


  2. I assume that the the sha1sum would be identical if the tarballs had identical contents? Would they differ if the files were created/modified at different times even if they have otherwise the same contents?


  3. Is there a better way to check if two tarballs have the same contents? That's all I am trying to do.







share|improve this question





















  • A tar archive contains information about ownership and timestamps on files, so to compare two archives generated on two separate machines would likely not work. You would be better off extracting the content of the two archives and comparing that. I'm not writing an answer because I don't know, off the top of my head, of a simple way of doing that.
    – Kusalananda
    2 days ago










  • For comparing two archives, there is no software sulution. Since 25 years, star however supports to compare an archive with the filesystem and allows to configure what to compare while doing that.
    – schily
    2 days ago










  • @schily what about this: tar -xOzf foo.tgz | sort | sha1sum
    – Alexander Mills
    2 days ago











  • Since -O usually tells tar to create archives compatible to the 1977 format, you seem to seem to use a different program. Let me assume that you have GNU tar in mind. With that tar clone and that command, the content of the files is extracted to stdout. If you did omit sort, you would get a definite value to compare tar archives with the same order of files inside. With the sort call, the result does not help you as you could get the same final result even in case there are differences.
    – schily
    yesterday












up vote
2
down vote

favorite









up vote
2
down vote

favorite











I create a .tgz/tarball with $(npm pack).



I then run:



sha1sum oresoftware-npp-0.0.1001.tgz 


and I get:



77c58da68593dcdcd14bb16a37f5f63ef42bab63 oresoftware-npp-0.0.1001.tgz


I want to compare that shasum against another tarball on a remote server.
I can query for a shasum for a tarball on the NPM registry, with:



 npm view @oresoftware/npp@latest dist.shasum


which yields:



3c2e7328110ba57e530c9938708b35bde941c419


this shasum is different than the other one above, but that's expected, since I changed the contents of the .tgz tarball file.



my question is 3 fold:



  1. When I generated a sha1sum of the .tgz file resulting from npm pack, is that the right way to do it? To generate the sha1sum after the tar file is created?


  2. I assume that the the sha1sum would be identical if the tarballs had identical contents? Would they differ if the files were created/modified at different times even if they have otherwise the same contents?


  3. Is there a better way to check if two tarballs have the same contents? That's all I am trying to do.







share|improve this question













I create a .tgz/tarball with $(npm pack).



I then run:



sha1sum oresoftware-npp-0.0.1001.tgz 


and I get:



77c58da68593dcdcd14bb16a37f5f63ef42bab63 oresoftware-npp-0.0.1001.tgz


I want to compare that shasum against another tarball on a remote server.
I can query for a shasum for a tarball on the NPM registry, with:



 npm view @oresoftware/npp@latest dist.shasum


which yields:



3c2e7328110ba57e530c9938708b35bde941c419


this shasum is different than the other one above, but that's expected, since I changed the contents of the .tgz tarball file.



my question is 3 fold:



  1. When I generated a sha1sum of the .tgz file resulting from npm pack, is that the right way to do it? To generate the sha1sum after the tar file is created?


  2. I assume that the the sha1sum would be identical if the tarballs had identical contents? Would they differ if the files were created/modified at different times even if they have otherwise the same contents?


  3. Is there a better way to check if two tarballs have the same contents? That's all I am trying to do.









share|improve this question












share|improve this question




share|improve this question








edited 2 days ago
























asked 2 days ago









Alexander Mills

1,834929




1,834929











  • A tar archive contains information about ownership and timestamps on files, so to compare two archives generated on two separate machines would likely not work. You would be better off extracting the content of the two archives and comparing that. I'm not writing an answer because I don't know, off the top of my head, of a simple way of doing that.
    – Kusalananda
    2 days ago










  • For comparing two archives, there is no software sulution. Since 25 years, star however supports to compare an archive with the filesystem and allows to configure what to compare while doing that.
    – schily
    2 days ago










  • @schily what about this: tar -xOzf foo.tgz | sort | sha1sum
    – Alexander Mills
    2 days ago











  • Since -O usually tells tar to create archives compatible to the 1977 format, you seem to seem to use a different program. Let me assume that you have GNU tar in mind. With that tar clone and that command, the content of the files is extracted to stdout. If you did omit sort, you would get a definite value to compare tar archives with the same order of files inside. With the sort call, the result does not help you as you could get the same final result even in case there are differences.
    – schily
    yesterday
















  • A tar archive contains information about ownership and timestamps on files, so to compare two archives generated on two separate machines would likely not work. You would be better off extracting the content of the two archives and comparing that. I'm not writing an answer because I don't know, off the top of my head, of a simple way of doing that.
    – Kusalananda
    2 days ago










  • For comparing two archives, there is no software sulution. Since 25 years, star however supports to compare an archive with the filesystem and allows to configure what to compare while doing that.
    – schily
    2 days ago










  • @schily what about this: tar -xOzf foo.tgz | sort | sha1sum
    – Alexander Mills
    2 days ago











  • Since -O usually tells tar to create archives compatible to the 1977 format, you seem to seem to use a different program. Let me assume that you have GNU tar in mind. With that tar clone and that command, the content of the files is extracted to stdout. If you did omit sort, you would get a definite value to compare tar archives with the same order of files inside. With the sort call, the result does not help you as you could get the same final result even in case there are differences.
    – schily
    yesterday















A tar archive contains information about ownership and timestamps on files, so to compare two archives generated on two separate machines would likely not work. You would be better off extracting the content of the two archives and comparing that. I'm not writing an answer because I don't know, off the top of my head, of a simple way of doing that.
– Kusalananda
2 days ago




A tar archive contains information about ownership and timestamps on files, so to compare two archives generated on two separate machines would likely not work. You would be better off extracting the content of the two archives and comparing that. I'm not writing an answer because I don't know, off the top of my head, of a simple way of doing that.
– Kusalananda
2 days ago












For comparing two archives, there is no software sulution. Since 25 years, star however supports to compare an archive with the filesystem and allows to configure what to compare while doing that.
– schily
2 days ago




For comparing two archives, there is no software sulution. Since 25 years, star however supports to compare an archive with the filesystem and allows to configure what to compare while doing that.
– schily
2 days ago












@schily what about this: tar -xOzf foo.tgz | sort | sha1sum
– Alexander Mills
2 days ago





@schily what about this: tar -xOzf foo.tgz | sort | sha1sum
– Alexander Mills
2 days ago













Since -O usually tells tar to create archives compatible to the 1977 format, you seem to seem to use a different program. Let me assume that you have GNU tar in mind. With that tar clone and that command, the content of the files is extracted to stdout. If you did omit sort, you would get a definite value to compare tar archives with the same order of files inside. With the sort call, the result does not help you as you could get the same final result even in case there are differences.
– schily
yesterday




Since -O usually tells tar to create archives compatible to the 1977 format, you seem to seem to use a different program. Let me assume that you have GNU tar in mind. With that tar clone and that command, the content of the files is extracted to stdout. If you did omit sort, you would get a definite value to compare tar archives with the same order of files inside. With the sort call, the result does not help you as you could get the same final result even in case there are differences.
– schily
yesterday










2 Answers
2






active

oldest

votes

















up vote
2
down vote













The checksums available from the NPM registry provide two features: they allow you to verify that your download hasn’t been corrupted, and if you can verify the checksums out of band, that the downloaded files haven’t been altered. Unless NPM archives are built reproducibly, the checksums don’t allow you to verify that an archive you build yourself using npm pack contains what it’s supposed to.



The issue with tarballs is that they contain metadata: the ownership, permissions and timestamps of the stored files, as stored by tar, and on top of that, compression metadata. If values for all of these are pre-agreed, they can be specified to override the values obtained from the file system, but that requires pre-agreement.



To compare the contents of two arbitrary tarballs, the only reliable way is to extract their contents and compare that.






share|improve this answer

















  • 1




    Thanks Stephen, so yes say I go through all the files in the tarball and compare them - name of file and size of file, can you maybe explain a good place to start with that? I don't care about file modification date, but I do care about file permissions. I figure if the file count across the tarballs is the same, the file names are the same, and all the file sizes are the same, then probably good enough.
    – Alexander Mills
    2 days ago







  • 1




    I reckon you should also compare the files’ contents; I wouldn’t consider comparing file names and sizes as sufficient.
    – Stephen Kitt
    2 days ago










  • In my testing, the shasum thing seems to work. I publish the tarball to NPM, then I retrieve the shasum from NPM. Then I copied the files with rsync to another local folder, and then generated a new tarball with npm pack and got the shasum, and it was the same as the one from the remote registry. Not sure how meaningful that is, but maybe the shasum works in this case. I have to read more about how sha1sum works.
    – Alexander Mills
    2 days ago










  • As an example, if you have a .tgz file in a Git repo, Git can tell you if that .tgz file changed, I just am not sure how exactly.
    – Alexander Mills
    2 days ago










  • something like this perhaps: stackoverflow.com/questions/51689992/…
    – Alexander Mills
    2 days ago

















up vote
0
down vote













Whether this checksum comparison is useful for you depends on what tar command you are using and that tar archive type is used.



star e.g. includes all three time stamps since 1986 and this causes tar archives to differ even with the same content, as the last acess time differs.



With the new POSIX tar enhancements from 2001, there are also all three time stamps - depending on whether the tar implementation implements the original standard or the later change.



If you don't care about time stamps, comparing archive checksums is not the right way to go.



Comparing two tar archives and making statements from that is thus usually impossible.



If you however may unpack one of the two archives, there is a nice way to compare content and meta data with a configurable set of meta data that is used for the comparison. Use star -diff, see http://schilytools.sourceforge.net/man/man1/star.1.html



If you e.g. call:



star -diff -v diffopts=!times < archive.tar.gz


the file content and all meta data except for all time stamps is compared.






share|improve this answer





















    Your Answer







    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "106"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    convertImagesToLinks: false,
    noModals: false,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );








     

    draft saved


    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f460539%2fcompare-tarballs-with-sha1sum%23new-answer', 'question_page');

    );

    Post as a guest






























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    2
    down vote













    The checksums available from the NPM registry provide two features: they allow you to verify that your download hasn’t been corrupted, and if you can verify the checksums out of band, that the downloaded files haven’t been altered. Unless NPM archives are built reproducibly, the checksums don’t allow you to verify that an archive you build yourself using npm pack contains what it’s supposed to.



    The issue with tarballs is that they contain metadata: the ownership, permissions and timestamps of the stored files, as stored by tar, and on top of that, compression metadata. If values for all of these are pre-agreed, they can be specified to override the values obtained from the file system, but that requires pre-agreement.



    To compare the contents of two arbitrary tarballs, the only reliable way is to extract their contents and compare that.






    share|improve this answer

















    • 1




      Thanks Stephen, so yes say I go through all the files in the tarball and compare them - name of file and size of file, can you maybe explain a good place to start with that? I don't care about file modification date, but I do care about file permissions. I figure if the file count across the tarballs is the same, the file names are the same, and all the file sizes are the same, then probably good enough.
      – Alexander Mills
      2 days ago







    • 1




      I reckon you should also compare the files’ contents; I wouldn’t consider comparing file names and sizes as sufficient.
      – Stephen Kitt
      2 days ago










    • In my testing, the shasum thing seems to work. I publish the tarball to NPM, then I retrieve the shasum from NPM. Then I copied the files with rsync to another local folder, and then generated a new tarball with npm pack and got the shasum, and it was the same as the one from the remote registry. Not sure how meaningful that is, but maybe the shasum works in this case. I have to read more about how sha1sum works.
      – Alexander Mills
      2 days ago










    • As an example, if you have a .tgz file in a Git repo, Git can tell you if that .tgz file changed, I just am not sure how exactly.
      – Alexander Mills
      2 days ago










    • something like this perhaps: stackoverflow.com/questions/51689992/…
      – Alexander Mills
      2 days ago














    up vote
    2
    down vote













    The checksums available from the NPM registry provide two features: they allow you to verify that your download hasn’t been corrupted, and if you can verify the checksums out of band, that the downloaded files haven’t been altered. Unless NPM archives are built reproducibly, the checksums don’t allow you to verify that an archive you build yourself using npm pack contains what it’s supposed to.



    The issue with tarballs is that they contain metadata: the ownership, permissions and timestamps of the stored files, as stored by tar, and on top of that, compression metadata. If values for all of these are pre-agreed, they can be specified to override the values obtained from the file system, but that requires pre-agreement.



    To compare the contents of two arbitrary tarballs, the only reliable way is to extract their contents and compare that.






    share|improve this answer

















    • 1




      Thanks Stephen, so yes say I go through all the files in the tarball and compare them - name of file and size of file, can you maybe explain a good place to start with that? I don't care about file modification date, but I do care about file permissions. I figure if the file count across the tarballs is the same, the file names are the same, and all the file sizes are the same, then probably good enough.
      – Alexander Mills
      2 days ago







    • 1




      I reckon you should also compare the files’ contents; I wouldn’t consider comparing file names and sizes as sufficient.
      – Stephen Kitt
      2 days ago










    • In my testing, the shasum thing seems to work. I publish the tarball to NPM, then I retrieve the shasum from NPM. Then I copied the files with rsync to another local folder, and then generated a new tarball with npm pack and got the shasum, and it was the same as the one from the remote registry. Not sure how meaningful that is, but maybe the shasum works in this case. I have to read more about how sha1sum works.
      – Alexander Mills
      2 days ago










    • As an example, if you have a .tgz file in a Git repo, Git can tell you if that .tgz file changed, I just am not sure how exactly.
      – Alexander Mills
      2 days ago










    • something like this perhaps: stackoverflow.com/questions/51689992/…
      – Alexander Mills
      2 days ago












    up vote
    2
    down vote










    up vote
    2
    down vote









    The checksums available from the NPM registry provide two features: they allow you to verify that your download hasn’t been corrupted, and if you can verify the checksums out of band, that the downloaded files haven’t been altered. Unless NPM archives are built reproducibly, the checksums don’t allow you to verify that an archive you build yourself using npm pack contains what it’s supposed to.



    The issue with tarballs is that they contain metadata: the ownership, permissions and timestamps of the stored files, as stored by tar, and on top of that, compression metadata. If values for all of these are pre-agreed, they can be specified to override the values obtained from the file system, but that requires pre-agreement.



    To compare the contents of two arbitrary tarballs, the only reliable way is to extract their contents and compare that.






    share|improve this answer













    The checksums available from the NPM registry provide two features: they allow you to verify that your download hasn’t been corrupted, and if you can verify the checksums out of band, that the downloaded files haven’t been altered. Unless NPM archives are built reproducibly, the checksums don’t allow you to verify that an archive you build yourself using npm pack contains what it’s supposed to.



    The issue with tarballs is that they contain metadata: the ownership, permissions and timestamps of the stored files, as stored by tar, and on top of that, compression metadata. If values for all of these are pre-agreed, they can be specified to override the values obtained from the file system, but that requires pre-agreement.



    To compare the contents of two arbitrary tarballs, the only reliable way is to extract their contents and compare that.







    share|improve this answer













    share|improve this answer



    share|improve this answer











    answered 2 days ago









    Stephen Kitt

    139k22296359




    139k22296359







    • 1




      Thanks Stephen, so yes say I go through all the files in the tarball and compare them - name of file and size of file, can you maybe explain a good place to start with that? I don't care about file modification date, but I do care about file permissions. I figure if the file count across the tarballs is the same, the file names are the same, and all the file sizes are the same, then probably good enough.
      – Alexander Mills
      2 days ago







    • 1




      I reckon you should also compare the files’ contents; I wouldn’t consider comparing file names and sizes as sufficient.
      – Stephen Kitt
      2 days ago










    • In my testing, the shasum thing seems to work. I publish the tarball to NPM, then I retrieve the shasum from NPM. Then I copied the files with rsync to another local folder, and then generated a new tarball with npm pack and got the shasum, and it was the same as the one from the remote registry. Not sure how meaningful that is, but maybe the shasum works in this case. I have to read more about how sha1sum works.
      – Alexander Mills
      2 days ago










    • As an example, if you have a .tgz file in a Git repo, Git can tell you if that .tgz file changed, I just am not sure how exactly.
      – Alexander Mills
      2 days ago










    • something like this perhaps: stackoverflow.com/questions/51689992/…
      – Alexander Mills
      2 days ago












    • 1




      Thanks Stephen, so yes say I go through all the files in the tarball and compare them - name of file and size of file, can you maybe explain a good place to start with that? I don't care about file modification date, but I do care about file permissions. I figure if the file count across the tarballs is the same, the file names are the same, and all the file sizes are the same, then probably good enough.
      – Alexander Mills
      2 days ago







    • 1




      I reckon you should also compare the files’ contents; I wouldn’t consider comparing file names and sizes as sufficient.
      – Stephen Kitt
      2 days ago










    • In my testing, the shasum thing seems to work. I publish the tarball to NPM, then I retrieve the shasum from NPM. Then I copied the files with rsync to another local folder, and then generated a new tarball with npm pack and got the shasum, and it was the same as the one from the remote registry. Not sure how meaningful that is, but maybe the shasum works in this case. I have to read more about how sha1sum works.
      – Alexander Mills
      2 days ago










    • As an example, if you have a .tgz file in a Git repo, Git can tell you if that .tgz file changed, I just am not sure how exactly.
      – Alexander Mills
      2 days ago










    • something like this perhaps: stackoverflow.com/questions/51689992/…
      – Alexander Mills
      2 days ago







    1




    1




    Thanks Stephen, so yes say I go through all the files in the tarball and compare them - name of file and size of file, can you maybe explain a good place to start with that? I don't care about file modification date, but I do care about file permissions. I figure if the file count across the tarballs is the same, the file names are the same, and all the file sizes are the same, then probably good enough.
    – Alexander Mills
    2 days ago





    Thanks Stephen, so yes say I go through all the files in the tarball and compare them - name of file and size of file, can you maybe explain a good place to start with that? I don't care about file modification date, but I do care about file permissions. I figure if the file count across the tarballs is the same, the file names are the same, and all the file sizes are the same, then probably good enough.
    – Alexander Mills
    2 days ago





    1




    1




    I reckon you should also compare the files’ contents; I wouldn’t consider comparing file names and sizes as sufficient.
    – Stephen Kitt
    2 days ago




    I reckon you should also compare the files’ contents; I wouldn’t consider comparing file names and sizes as sufficient.
    – Stephen Kitt
    2 days ago












    In my testing, the shasum thing seems to work. I publish the tarball to NPM, then I retrieve the shasum from NPM. Then I copied the files with rsync to another local folder, and then generated a new tarball with npm pack and got the shasum, and it was the same as the one from the remote registry. Not sure how meaningful that is, but maybe the shasum works in this case. I have to read more about how sha1sum works.
    – Alexander Mills
    2 days ago




    In my testing, the shasum thing seems to work. I publish the tarball to NPM, then I retrieve the shasum from NPM. Then I copied the files with rsync to another local folder, and then generated a new tarball with npm pack and got the shasum, and it was the same as the one from the remote registry. Not sure how meaningful that is, but maybe the shasum works in this case. I have to read more about how sha1sum works.
    – Alexander Mills
    2 days ago












    As an example, if you have a .tgz file in a Git repo, Git can tell you if that .tgz file changed, I just am not sure how exactly.
    – Alexander Mills
    2 days ago




    As an example, if you have a .tgz file in a Git repo, Git can tell you if that .tgz file changed, I just am not sure how exactly.
    – Alexander Mills
    2 days ago












    something like this perhaps: stackoverflow.com/questions/51689992/…
    – Alexander Mills
    2 days ago




    something like this perhaps: stackoverflow.com/questions/51689992/…
    – Alexander Mills
    2 days ago












    up vote
    0
    down vote













    Whether this checksum comparison is useful for you depends on what tar command you are using and that tar archive type is used.



    star e.g. includes all three time stamps since 1986 and this causes tar archives to differ even with the same content, as the last acess time differs.



    With the new POSIX tar enhancements from 2001, there are also all three time stamps - depending on whether the tar implementation implements the original standard or the later change.



    If you don't care about time stamps, comparing archive checksums is not the right way to go.



    Comparing two tar archives and making statements from that is thus usually impossible.



    If you however may unpack one of the two archives, there is a nice way to compare content and meta data with a configurable set of meta data that is used for the comparison. Use star -diff, see http://schilytools.sourceforge.net/man/man1/star.1.html



    If you e.g. call:



    star -diff -v diffopts=!times < archive.tar.gz


    the file content and all meta data except for all time stamps is compared.






    share|improve this answer

























      up vote
      0
      down vote













      Whether this checksum comparison is useful for you depends on what tar command you are using and that tar archive type is used.



      star e.g. includes all three time stamps since 1986 and this causes tar archives to differ even with the same content, as the last acess time differs.



      With the new POSIX tar enhancements from 2001, there are also all three time stamps - depending on whether the tar implementation implements the original standard or the later change.



      If you don't care about time stamps, comparing archive checksums is not the right way to go.



      Comparing two tar archives and making statements from that is thus usually impossible.



      If you however may unpack one of the two archives, there is a nice way to compare content and meta data with a configurable set of meta data that is used for the comparison. Use star -diff, see http://schilytools.sourceforge.net/man/man1/star.1.html



      If you e.g. call:



      star -diff -v diffopts=!times < archive.tar.gz


      the file content and all meta data except for all time stamps is compared.






      share|improve this answer























        up vote
        0
        down vote










        up vote
        0
        down vote









        Whether this checksum comparison is useful for you depends on what tar command you are using and that tar archive type is used.



        star e.g. includes all three time stamps since 1986 and this causes tar archives to differ even with the same content, as the last acess time differs.



        With the new POSIX tar enhancements from 2001, there are also all three time stamps - depending on whether the tar implementation implements the original standard or the later change.



        If you don't care about time stamps, comparing archive checksums is not the right way to go.



        Comparing two tar archives and making statements from that is thus usually impossible.



        If you however may unpack one of the two archives, there is a nice way to compare content and meta data with a configurable set of meta data that is used for the comparison. Use star -diff, see http://schilytools.sourceforge.net/man/man1/star.1.html



        If you e.g. call:



        star -diff -v diffopts=!times < archive.tar.gz


        the file content and all meta data except for all time stamps is compared.






        share|improve this answer













        Whether this checksum comparison is useful for you depends on what tar command you are using and that tar archive type is used.



        star e.g. includes all three time stamps since 1986 and this causes tar archives to differ even with the same content, as the last acess time differs.



        With the new POSIX tar enhancements from 2001, there are also all three time stamps - depending on whether the tar implementation implements the original standard or the later change.



        If you don't care about time stamps, comparing archive checksums is not the right way to go.



        Comparing two tar archives and making statements from that is thus usually impossible.



        If you however may unpack one of the two archives, there is a nice way to compare content and meta data with a configurable set of meta data that is used for the comparison. Use star -diff, see http://schilytools.sourceforge.net/man/man1/star.1.html



        If you e.g. call:



        star -diff -v diffopts=!times < archive.tar.gz


        the file content and all meta data except for all time stamps is compared.







        share|improve this answer













        share|improve this answer



        share|improve this answer











        answered 2 days ago









        schily

        8,38721435




        8,38721435






















             

            draft saved


            draft discarded


























             


            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f460539%2fcompare-tarballs-with-sha1sum%23new-answer', 'question_page');

            );

            Post as a guest













































































            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Displaying single band from multi-band raster using QGIS

            How many registers does an x86_64 CPU actually have?