That was a “fun” debugging session…
Just bear in mind that uid 1001 on one machine is not generally uid 1001 on another, and that if you copy the tar off machine you’re more than likely giving permission to somebody other than the intended target
That’s a feature, not a bug. It’s an archive after all.
It’s even a tape archiving tool. Just pretty much nobody uses it in the original way any more.
Very much one of those “if it ain’t broke, don’t replace it” tools.
but also the way it puts file data one after the other can be beneficial for compression, especially if you can define the order of the files somehow
I just assumed that whenever it would be expanded that the contents would have the default permissions for that user.
It’s actually a cool feature I just feel dumb for how long it took me to realize this was the issue.
that can be done too. tarballed software normally doesn’t have permissions attached I think
Yeah I did notice that. Never really had a use for such a feature though.
That’s what an archiving program is supposed to do.
You can even archive extended attributes with the
‘--xattrsflag.Good to know if you use xattrs as a tagging system.
I’ve never heard of an archiving program that didn’t.
mostly anything on windows
I thought that, since users would be different between machines, there’s no point in keeping this kind of information.
You can sync user and daemon UIDs across machines with LDAP and SSSD.
And even if you don’t do that, keeping the information is useful when restoring to the same machine
IIRC zip can, but doesn’t by default. Source : wasted 8 hours trying to figure out why something didn’t work anymore (had to switch from tar to zip because stupid security system wouldn’t let me transfer the tar file)
tard -czf <folder> mv folder.{tar.gz,zip}Just use archive.pdf
Learned to make use of this the hard way when transferring a directory over a FAT32 USB drive messed up the permissions.
