Open alem0lars-yr opened 8 years ago
The bug may be present only when there are conflicts to be resolved.
In fact, the conflict resolution is handled internally by thor that uses the block form for creating the temporary file.
Taking a look at the ruby documentation we see:
Tempfile.open('foo', '/home/temp') do |f|
... do something with f ...
end
# Equivalent:
f = Tempfile.open('foo', '/home/temp')
begin
... do something with f ...
ensure
f.close
end
This shows that internally uses: f.close
:
close(unlink_now=false)
Closes the file. If unlink_now is true, then the file will be unlinked (deleted) after closing. Of course, you can choose to later call unlink if you do not unlink it now.
If you don’t explicitly unlink the temporary file, the removal will be delayed until the object is finalized.
As we can see the problem may be that unlink_now
is set to false
, the removal will be delayed until the object is finalized.
In conclusion, the file isn't removed instantly but instead when the Ruby's VM decides to dispose the object.
This could be the problem since right after the instatiation we trigger the installation that links every file available there, including the fucking temporary file.
@jak3 what do you think about?
Maybe remove thor should be an option. How much work do you think is needed in order to replace it functionalities?
I'd really like to remove thor, this will allow us to implement ad-hoc features and to be dependency-less.. However, it costs a lot of time because we need to implement a custom command-based parser (similar to thor) and custom low level I/O operations.. Also removing thor enables us to solve some more issues related to that gem.
Fizzy install links temporary files..