> > https://github.com/tcurdt/jdeb/issues/241 > > [WRT to that issue, LONGFILE_POSIX should be the preferred option if it > works in debs. LONGFILE_GNU is considered deprecated even by GNU tar.] >
Thanks! I will give that a try. > and I have to say I was a little confused about the docs on the AR support > > in compress > > > https://commons.apache.org/proper/commons-compress/examples.html > > >> Commons Compress 1.0 to 1.2 can only read archives using the GNU/SRV4 > >> variant, support for the BSD variant has been added in Commons Compress > >> 1.3. Commons Compress 1.3 also optionally supports writing archives with > >> file names longer than 16 characters using the BSD dialect, writing the > >> SVR4/GNU dialect is not supported. > > Please help us improve it. To me (the one who wrote the paragraph) it is > totally clear. ;-) > Happy to :) Should it explicitly state that all versions of Compress can read and > write the original format that is limited to 16 char names? > I think I'd just add a little table. OK? > Is this what it means? > > > 1.0: > > Original: r/w > > GNU/SRV4: r > > BSD: unsupported > > > 1.2: > > Original: r/w > > GNU/SRV4: r > > BSD: unsupported > > > 1.3+: > > Original: r/w > > GNU/SRV4: r > > BSD: r/w > > Yes. > Cool. Thanks! I got one more thing... :) I just found a new issue with compress. It's the "normalizeFileName" in TarArchiveEntry again. On Windows it just strips the drive letter https://github.com/apache/commons-compress/blob/master/src/main/java/org/apache/commons/compress/archivers/tar/TarArchiveEntry.java#L1337 which I think is a questionable default behaviour IMO. TarArchiveEntry("C:\foo\bar") -> "/foo/bar" TarArchiveEntry("D:\foo\bar") -> "/foo/bar" Is that in line with how other unix tool ports handle things on windows? cheers, Torsten
