TempFile#unlink - do not work if #close is not called right before, even if nothing has been done over the file. #678

robertodecurnex opened this Issue Apr 29, 2013 · 3 comments

2 participants

  temp_file = TempFile.new('name')

That won't blow nor delete the file.

Right now it just logs a warning asking to close the file before unlink.

That make sense if the file is actually opened but TempFile.new show create the file and the file reference without opening the stream.

Note that the problem is not present on other Ruby implementations.

Btw, the following will work great.

  temp_file = TempFile.new('name')

Here is a previous discussion about the issue


JRuby Team member

I'm not sure what we can do here.

The original fix (changing to a no-op for JRUBY-6477) was done because we have no way to unlink the file without deleting it and making the stream useless, as is sometimes done to help secure a temporary file (since it will have no dir entry but still remain open and usable). We modified that fix in JRUBY-6688 to actually delete the file if it has already been closed and warn otherwise because it was obviously confusing to have unlink do nothing. My hope was that the warning would be sufficient to tell folks they need to close the file first, and it seems to have brought you to the right point with your code.

If we go all the way back to actually deleting the file, then JRUBY-6477 will be undone. I don't think we can do that.

It might be possible for us to do an actual unlink by using a native downcall via FFI, but I'm reluctant to do that because there will be no equivalent for environments where we can't use native code (or on Windows, where I don't think you can unlink and continue to access a file).

Sorry, but I think this is a wontfix. Just close the file first and you'll be ok.

@headius headius closed this Apr 30, 2013

Ok, I can live with it, adding the #close do not break the rest of the builds. Also, I have to admit that this is an edge case. I just freak out when thigs do not work exacly the same from one implementation to the other :P

Thank you for your time!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment