[compress] long uid/gids in tests (was Re: [DISCUSS] Release Compress 1.21 based on RC1)

[Stefan Bodewig <bo...@apache.org>]

>> Are there any tests that actually use the uid/gid of the current user?
>> Compress will no read them by itself, so the only place things could
>> fail was if we used native tar to create an archive. Is there such a
>> test? If so we could try to adapt the test in question.

On 2021-07-10, Henri Biestro wrote:

> Any test based on creating/reading a file from what I gather;

Yes, you are certainly correct, please forgive me. When support for
Paths has been added the code started to use NIO features to obtain the
uid/gid from PosixFileAttributes if available. I must admit I haven't
been aware of that.

Personally I still believe we shouldn't be setting bignumbermode without
users explicitly asking for it. Of course our own tests are a different
beast. OS detection likely will not help, uids that big may occur on
other platforms than the Mac as well, I guess.

One option would be to explicitly use BIGNUMBER_POSIX in tests - except
those tests where it would hurt, of course.

> Another mitigation could be modifying failForBigNumbers to reset
> uid/gid (aka set to 0L or nobody's id?) instead of failing when they
> are problematic for the chosen TAR format.

This is a crude case if not being backwards compatible, I'm afraid. 0
doesn't look like a good default and I don't believe there is an agreed
upon uid for nobody.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org