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.

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

Fizzy install links temporary files #25

Open
alem0lars-yr opened this issue Jul 1, 2016 · 4 comments
Open

Fizzy install links temporary files #25

alem0lars-yr opened this issue Jul 1, 2016 · 4 comments

Comments

@alem0lars-yr
Copy link
Collaborator

alem0lars-yr commented Jul 1, 2016

Fizzy install links temporary files..

2016-07-01-232342_1266x825_scrot


Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

@alem0lars
Copy link
Owner

alem0lars commented Sep 13, 2016

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.

@alem0lars
Copy link
Owner

alem0lars commented Sep 13, 2016

@jak3 what do you think about?

@jak3
Copy link
Collaborator

jak3 commented Sep 14, 2016

Maybe remove thor should be an option. How much work do you think is needed in order to replace it functionalities?

@alem0lars
Copy link
Owner

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.

@alem0lars alem0lars reopened this Sep 8, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants