Regardless of whether this could have been done differently, there is one very important fact to keep in mind:
Tar has been around for a very long time (nearly 50 years) and there are many programs that read and write them — quite likely thousands by this point. It is critically important that tar archives written by one implementation be able to be read by other implementations. Changes of the sort you suggest here are simply not possible to make today. Tim > On Feb 29, 2024, at 12:29 PM, Vishal Kohli <vish.k...@gmail.com> wrote: > > Hi > > On my quest for info I found this email on this page: bug-tar Info Page > (gnu.org) <https://lists.gnu.org/mailman/listinfo/bug-tar>. > > The page suggests that I should send an email and it would reach the GNU > maintainers. So if I have reached you by mistake, please ignore this email. > ---------------------------------- > > Now to topic, > > I came across the concept of Tar blocking today. As per wikipedia (Under > 'File Format' section): > " most modern tar implementations fill the extra space with zeros. " > > My question is why is the last (and only last) block not of variable size? If > it was, bytes of data stored could be recorded using 2 bytes. This metadata > can be stored in the header. > > To me, this is much more efficient than wasting 511 bytes (by zeroing) in a > 512 blocking system. The number of bytes used to store metadata about the > last block can vary depending on the blocking size used. > > I understand that one most common argument is who cares about a couple of > bytes when storage is cheap. But I care. > > What do you think about this? Is there anything that I may have missed? > > Sincerely
