Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is it possible to save and restore original File Modification Date/Time of nsp? #161

Open
msdos opened this issue Dec 7, 2023 · 2 comments

Comments

@msdos
Copy link

msdos commented Dec 7, 2023

Although decompressing creates a nsp with same checksum, file modification date/time is changed since the original nsp container is destroyed and recreated.

Is it possible to keep these original properties somewhere in nsz container and, when decompressing, be set again in original nsp?

Don't know if this is technically possible, so you can close this issue if it's not feasible.

(And... If setting arbitrary metadata inside nsz is possible, another enhancement would be save which nsz version created a .nsz file. This would be a really nice addition for debugging)

@Masamune3210
Copy link

That would take altering the format, which is unlikely to be done for something like this.

@nicoboss
Copy link
Owner

nicoboss commented Dec 7, 2023

We are just talking about file metadata here. It would be possible to add a flag to copy over such metadata to the NSZ file when compressing and then copy it back to the NSP when decompressing. Doing so does not require altering the NSZ file format in any way. File metadata is unfortunately highly OS and file system dependent. Such metadata is not stored inside the file but part the file system. An application is usually not supposed to modify this but most operating systems allow applications to do so anyway. There are some limitations. For example, on Linux atime and mtime can be changes by software while ctime can only be changed by the kernel and so out of reach of any application. It makes a lot of sense that such metadata is reset when compressing/decompressing a file as a new file as is created. This is probably what the vast majority of users expect. So not preserving such metadata will likely stay the default behavior but I’m fine adding a command line argument for this. This issue is quite low priority but also barely requires any work so no idea when I will implement this. Feel free to create a pull request if you want to implement it by your own.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants