Preserve file modification timestamps in ZIP archives #326
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Hello. Thank you for your contribution. This is on the backlog for a long time and your code will help finish it sooner. :-) |
mmso
force-pushed
the
main
branch
4 times, most recently
from
b507a1d
to
dced0a5
Compare
Currently, files in downloaded ZIP archives have current time as a modification time, even though the modification time is preserved on the server side when uploading files. That seems like a regression to me, since a sequence of upload-download effectively erases this metadata, which is unexpected, inconvenient at best and may result in a complete loss. I can imagine (1) moving files from some place to ProtonDrive, then (2) moving these files or some subset of them out of ProtonDrive. No backups from (1) and erase ProtonDrive's copy at (2) without checking timestamps during the move results in a loss. If one happened to have backups and ProtonDrive's copy is earsed, that may be a partial loss if files have been modified in ProtonDrive between (1) and (2). If ProtonDrive's copy is accessible during or after (2) and there are no backups from (1) or there were changes in ProtonDrive between (1) and (2), prepare for manual timestamp mangling which may as well be infeasible depending on the number of files. The timestamp is currently set by `client-zip`, where `new Date()` is a default when input is `ReadableStream<Uint8Array>` and no `lastModified` provided. Since `fileModifyTime` is already present on a `DecryptedLink`, just pass that through to `archiveGenerator` and set `lastModified`.
mmso
force-pushed
the
main
branch
10 times, most recently
from
e7ff858
to
62e46e0
Compare
mmso
force-pushed
the
main
branch
10 times, most recently
from
82d1bc0
to
d04bb1e
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi there,
You seem to be accepting contributions, so I thought I'd go that route instead of support. The commit message describes the problem.
The only downside is that I could not test the change end-to-end due to #322 and I did not want to spend more time on the issue trying to work around that. I'd expected
unzip -lon a downloaded archive show timestamps that are displayed in the web UI. All I can say is that according to theclient-zipdocumentation and my quick glance over your codebase that should work. Feel free to change the commit as you see fit.