On Sat, Feb 13, 2016 at 2:45 AM, Otto Moerbeek <[email protected]> wrote: > On Fri, Feb 12, 2016 at 11:48:11PM -0500, Peter Bisroev wrote: > > ... > > This problem is already being discussed on bugs@ (with a different diff). > I suggest to send this diff to bugs@ to keep the converation in one place. > http://marc.info/?t=145495481100003&r=1&w=2
Hi Otto, thank you for pointing this out, looking at the submission dates I see why I have missed that post. I saw this issue last week but did not file a bug report at that time. So when I did send it through there was one already. Will double check next time to avoid this race condition :). Sorry, my fault. The diff on that thread appears to be the same as mine here, except for the comments. Should I still send it through or just leave it here and keep that thread clean? >> Also, there is another tricky issue which still exhibits proper behavior >> according to the spec: >> >> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_06 >> yet it is not very consistent. >> >> If there is a directory name which is exactly 155 bytes long, and this >> directory is being archived, pax will complain that that directory name is >> too >> long, yet it will archive the files underneath that directory assuming they >> fit into the TNMSZ name limit. >> >> In circumstances like these, what would be the most appropriate behavior for >> pax? Because if that directory is empty, it will not be archived, but if >> there >> is even a single file underneath it pax will complain, but still archive this >> directory without an error when it is archiving the actual file. >> >> Please let me know if I can help further. > > This problem is related but different, I'll Cc: guenther to bring this to > his attention. > > -Otto Thank you Otto! --peter
