[go: nahoru, domu]
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.

Sign up for GitHub

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

Jump to bottom

No files timestamps in zip file #153

Open
joerg-krause opened this issue Dec 23, 2015 · 7 comments
Open

No files timestamps in zip file #153

joerg-krause opened this issue Dec 23, 2015 · 7 comments

Comments

@joerg-krause
Copy link
Contributor

Unzipping the zipped release file fetched from https://lit.luvit.io/packages/luvit/lit using unzip on Linux gives a wrong timestamp:

$ unzip v2.3.1.zip -d lit-2.3.1

$ ls -l /home/joerg/lit-2.3.1/main.lua 
-rw-r--r-- 1 joerg joerg 1951 31. Dez 1979  /home/joerg/lit-2.3.1/main.lua

$ stat /home/joerg/lit-2.3.1/main.lua
Access: 1979-12-31 00:00:00.000000000 +0100
Modify: 1979-12-31 00:00:00.000000000 +0100
Change: 2015-12-23 22:15:55.132868757 +0100

I've checked the zip files, and the files have a zero timestamp now. I'm not sure, if this may cause some trouble in some systems.

EDIT: I realized that the files are not fetched from lit install, but from wget and using unzip on the fetched zip file.
@joerg-krause joerg-krause changed the title Using lit install gives wrong file timestamps No files timestamps in zip file Dec 23, 2015
@creationix
Copy link
Member

Yes, I no-longer include the timestamps because it's very hard to get the actual timestamp and I need something that doesn't change between builds.

I suppose I could walk back in history of the git tags (by decrementing the version number and seeing if such a tag exists) and seeing when the contents of a file at a certain path change. This would be a very expensive and hard to do algorithm.

@joerg-krause
Copy link
Contributor Author

How about caching a release file?

@creationix
Copy link
Member

Caching could be done, but if the cache was ever cleared then the release hash would change. So this is more than just caching for optimization sake, it would need stronger guarantees.

Also is there any real problem with files not having valid timestamps?

@joerg-krause
Copy link
Contributor Author

Sorry for my ignorance, but why not create a release tarball (by the author), store it on the server (like github does), and fetch it by lit?

There are some cloud data tools relying on a files timestamps, e.g. ownCloud. Maybe there are some other reasons (maybe security?) I do not know of.

@creationix
Copy link
Member

What if all files had the timestamp of the git tag for the release? Then they would be consistent and relatively accurate. I would need to add in the functionality to miniz to allow custom timestamps (currently the only options are "current time" or "no timestamp"). But this wouldn't be the first time I've added features or fixed bugs in miniz for luvi.

@joerg-krause
Copy link
Contributor Author

Good idea! This way the files would have a sane timestamp.

@creationix
Copy link
Member

See luvit/luvi#133 for progress. Then adding the functionality to lit should be easy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@creationix @joerg-krause