Is ././@LongLink included in a tarball unconditionally?
Opened this issue · 3 comments
Is ././@LongLink included in a tarball unconditionally? I don't remember seeing that in 3.1.6 (possibly, the long filenames support was added or somehow fixed later). In my understanding, there is no need to include ././@LongLink if none of the filenames (sub-paths) exceeds the length limit. In my case, the longest sub-path was only 118 characters.
It might even confuse users if they receive and open such file in order to extract. And by the way, the standard tar didn't include ././@LongLink in my case.
It's been a while since I've been able to work on this, so I don't remember much of anything at the moment. A quick look at the code, in tar_encoder.dart I see it adds @LongLink for files with names > 100 characters. tar_file.dart, when reading the file header, filename size in the header is 100 bytes. Seems to be where the 100 limit for adding a @LongLink file comes from.
Any format spec details beyond that, I don't remember at the moment. If you have some info that would let it work without a @LongLink file and names > 100 characters, I could look into improving it.
Thank you, Brendan.
I found this description on gnu.org: https://www.gnu.org/software/tar/manual/html_section/Formats.html
It states that according to the archive format defined by POSIX.1-2001 specification, there is no limit on the filename or sub-path length. Is it possible to implement such behaviour? If you still prefer to support the old v7 specification (up to 99 characters, not 100), then it would be nice to avoid extraction of ././@LongLink. Unfortunately, when I did 'extract everything' with tar on Linux, that file was extracted too (with no permission set). And although on Linux it will not be listed in GUI (like Dolphin File Manager), it is still not a very good thing. Plus, I'm pretty sure it will be visible on Windows. There must be the way to prevent extraction of such file irrespective the application. However, if that's not possible, I think, the best way would be to remove the limit at all. Most likely, POSIX.1-2001 exists for more than 20 years since 2001.
That's certainly a possibility, but I doubt I'll have time to do it any time soon.