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

File.mtime doesn't return a useful value for a file in a jar #3812

Open
bigsur0 opened this issue Apr 19, 2016 · 3 comments
Open

File.mtime doesn't return a useful value for a file in a jar #3812

bigsur0 opened this issue Apr 19, 2016 · 3 comments
Milestone
Won't Fix

Comments

@bigsur0
Copy link
Contributor

bigsur0 commented Apr 19, 2016 •
edited
Loading

Symptom

Sinatra AssetPack fails to get a valid Last-Modified time from an asset packaged in a JAR causing upstream processing by Rack::Deflater to fail.

Environment

jruby-9.0.3.0
Linux & Mac (when running from a jar archive)
Using Sinatra, Sinatra AssetPack, and Rack::Deflater

Expected Behavior

When Rack goes to read the static asset from the jar file via the classpath: scheme it should provide a File object that returns useful Time object for File.mtime, so that when the Last-Modified header is read and parsed upstream processing w/ Rack::Deflater it can appropriately parse the Time string.

Actual Behavior

It throws an ArgumentError @: https://github.com/headius/jruby/blob/master/lib/ruby/2.0/time.rb#L505

Another useful line just above the previous link in the stack : https://github.com/rack/rack/blob/master/lib/rack/deflater.rb#L58

What should File.mtime return for a file in a jar? The modified time for the file or at a minimum the modified time for the jar? Here's an example.

$ java -jar jruby-complete-9.0.3.0.jar -e 'load "META-INF/jruby.home/bin/jirb"'
>> File.exists?("classpath:META-INF/jruby.home/bin/jirb")
=> true
>> File.mtime("classpath:META-INF/jruby.home/bin/jirb")
=> 1969-12-31 16:00:00 -0800
>> File.mtime("classpath:META-INF/jruby.home/bin")
=> 1969-12-31 16:00:00 -0800
@kares
Copy link
Member

kares commented Jun 12, 2018

this isn't really possible - for a resources on classpath: we simply get a stream no notion of a "file" ...
however, if you're about to use the jar: protocol (not-applicable to this case) it should be working.

@kares kares added this to the Won't Fix milestone Jun 12, 2018
@headius
Copy link
Member

headius commented Jun 12, 2018

I agree there's no way for us to get a proper mtime for opaque classpath resources. I guess @r6p doesn't feel that the epoch is a good enough fallback for this case? It represents "time zero" on the unix clock, and if we have to provide something it seems like this is the best option.

What else would we use? 00:00:00 on 0001-01-01? I can't think of anything that would not cause problems.

@kares
Copy link
Member

kares commented Jun 13, 2018

What should File.mtime return for a file in a jar? The modified time for the file or at a minimum the modified time for the jar?

believe the reporter desires to have it reasonable since there are compiled assets being mtime compared.
so a different fallback won't do much - believe the epoch fallback is fine since that is a common thing to do.

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
Won't Fix
Development

No branches or pull requests
3 participants
@headius @bigsur0 @kares