On Tue, Sep 3, 2019 at 12:46 PM Ibrar Ahmed <ibrar.ah...@gmail.com> wrote: > I did that and have experience working on the TAR format. I was curious > about what > "best/newest" you are talking.
Well, why not go look it up? On my MacBook, tar is documented to understand three different tar formats: gnutar, ustar, and v7, and two sets of extensions to the tar format: numeric extensions required by POSIX, and Solaris extensions. It also understands the pax and restricted-pax formats which are derived from the ustar format. I don't know what your system supports, but it's probably not hugely different; the fact that there are multiple tar formats has been documented in the tar man page on every machine I've checked for the past 20 years. Here, 'man tar' refers the reader to 'man libarchive-formats', which contains the details mentioned above. A quick Google search for 'multiple tar formats' also finds https://en.wikipedia.org/wiki/Tar_(computing)#File_format and https://www.gnu.org/software/tar/manual/html_chapter/tar_8.html each of which explains a good deal of the complexity in this area. I don't really understand why I have to explain to you what I mean when I say there are multiple tar formats when you can look it up on Google and find that there are multiple tar formats. Again, the point is that the current code only generates tar archives and therefore only needs to generate one format, but if we add code that reads a tar archive, it probably needs to read several formats, because there are several formats that are popular enough to be widely-supported. It's possible that somebody else here knows more about this topic and could make better judgements than I can, but my view at present is that if we want to read tar archives, we probably would want to do it by depending on libarchive. And I don't think we should do that for this project because I don't think it would provide much value. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
