[1718627440]

Isn't this what is already common in the Python community?

> I don't want to unpack an archive and have to scrutinize it for files with o+rxst permissions, or have their creation date be anything other than when I unpacked them.

I'm the opposite, when I pack and unpack something, I want the files to be identical including attributes. Why should I throw away all the timestamps, just because the file were temporarily in an archive?

[nh2]

There is some confusion here.

ZIP retains timestamps. This makes sense because timestamps are a global concept. Consider them a attribute dependent on only the file in ZIP, similar to the file's name.

Owners and permissions are dependent also on the computer the files are stored on. User "john" might have a different user ID on another computer, or not exist there at all, or be a different John. So there isn't one obvious way to handle this, while there is with timestamps. Archiving tools will have to pick a particular way of handling it, so you need to pick the tool that implements the specific way you want.

[pwg]

> ZIP retains timestamps.

It does, but unless the 'zip' archive creator being used makes use of the extensions for high resolution timestamps, the basic ZIP format retains only old MSDOS style timestamps (rounded to the closed two seconds). So one may lose some precision in ones timestamps when passing files through a zip archive.

[nh2]

That's correct. I think it is not hard to use the high resolution timestamps, but still they do not have the same precision as a UNIX tv_nsec value, which can be annoying if you want to preserve the _exact_ time that common Linux filesystems can store.

[password4321]

> Why should I throw away all the timestamps, just because the file were temporarily in an archive?

In case anyone is unaware, you don't have to throw away all the timestamps when using "zip with no compression". The metadata for each zipped file includes one timestamp (originally rounded to even number of seconds in local time).

I am a big last modified timestamp fan and am often discouraged that scp, git, and even many zip utilities are not (at least by default).

[rcxdude]

git updates timestamps in part by necessity of compatibility with build systems. If it applied the timestamp of when the file was last modified on checkout then most build systems would break if you checked out an older commit.

[ralferoo]

git blame is more useful than the file timestamp in any case.

[Dylan16807]

> I'm the opposite, when I pack and unpack something, I want the files to be identical including attributes. Why should I throw away all the timestamps, just because the file were temporarily in an archive?

I would expect modified dates to stay the same, and other dates to change similar to copying a directory. I think this is the normal experience with zip?

For creation dates, Linux usually doesn't even track those at all. There's partial support on BTRFS and ZFS, and on ext4 there nowhere to store it at all.

[rustyhancock]

Yes, it's a lossy process.

If your archive drops it you can't get it back.

If you don't want it you can just chmod -R u=rw,go=r,a-x

[1718627440]

> If your archive drops it you can't get it back.

Hence, the common archive format is tar not zip.

[zahlman]

> Isn't this what is already common in the Python community?

I'm not aware of standards language mandating it, but build tools generally do compress wheels and sdists.

If you're thinking of zipapps, those are not actually common.

[1718627440]

I was talking about using zipfile as a generic file format, instead of open and close.

[zahlman]

I'm afraid I don't understand specifically what you're referring to. Maybe you could show some code citations of popular projects doing it?