MacPaw/XADMaster

lsar v1.10.1 difficulty with PAXHeaders and truncating long paths

ross-spencer opened this issue · 0 comments

@prettybits and I are looking into some unar/lsar issues. We're seeing Unar truncate paths over a certain length. This first shows up in lsar where it can't report on the path correctly either.

To recreate

# create a long path.
echo "data" > this-is-a-test-archive-fact-1970-01-01T00-00-00Z-data-message-AAA-AAA-service1-collector-0.0.0-dev-1970-01-0T1-00-00-00Z.json

# use GNU tar with the PAX argument to create a tar.
tar -H pax -c -f gnu_tar_long.tar this-is-a-test-archive-fact-1970-01-01T00-00-00Z-data-message-AAA-AAA-service1-collector-0.0.0-dev-1970-01-0T1-00-00-00Z.json

# optionally, use Python 3.
python -m tarfile -c python_tar_long.tar this-is-a-test-archive-fact-1970-01-01T00-00-00Z-data-message-AAA-AAA-service1-collector-0.0.0-dev-1970-01-0T1-00-00-00Z.json

Output

$ lsar gnu_tar_long.tar 
gnu_tar_long.tar: Tar
this-is-a-test-archive-fact-1970-01-01T00-00-00Z-data-message-AAA-AAA-service1-collector-0.0.0-dev-1

$ lsar python_tar_long.tar 
python_tar_long.tar: Tar
this-is-a-test-archive-fact-1970-01-01T00-00-00Z-data-message-AAA-AAA-service1-collector-0.0.0-dev-1

$ lsar -version
v1.10.1

I am not an Objective C coder so I haven't looked into the underlying implementation. I haven't seen a similar issue reported on this repository either.

Expected behavior

The listing is accurate, or potentially, the discrepancy can be detected and reported on as a warning.