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
Try using @tempfile.size for TempObject#size #318
Conversation
thanks - though I see the Travis build is failing as a number of sizes in tests (ruby 1.8.7) are reporting size as zero (do you know why this is?) https://travis-ci.org/markevans/dragonfly/builds/18384163 |
Yup, I saw that -- I will take a look. |
any update on this? if not I'll close if you don't mind |
Yup, sorry - had some trouble installing 1.8.7 - looking at it now. |
I found the issue. In 1.8.7, a Tempfile object will report a size of 0 after it's been closed - even if it has data and hasn't been unlinked yet. This problem is fixed in 1.9+, so I've added a core_ext to address it in 1.8.7 |
cool thanks. is this a well-known bug in 1.8.7? just asking coz in general I'm reluctant to introduce core extensions unless really necessary. |
Reaching EOL in a couple of weeks, I don't think this bug will be fixed in https://www.ruby-lang.org/en/news/2014/07/01/eol-for-1-8-7-and-1-9-2/ @markevans that said, how long do you think you'll support 1.8.7 for this On Monday, July 14, 2014, Mark Evans notifications@github.com wrote:
|
fair enough. good point - not forever (especially now that 1.8.7 support is ending) |
Try using @tempfile.size for TempObject#size
If
@tempfile
is available, TempObject should be checking@tempfile.size
instead of doing equivalent ofFile.size(@tempfile.path)
. In my particular case,@tempfile
is actually a delegate to a remote (S3) object that separately (and lazily) pulls metadata (like size) and the file contents. This change would prevent the file contents to be fetched to disk to just compute the file size.