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

Better multi-user support for fig-home #73

Closed
klimkin opened this issue Mar 22, 2014 · 1 comment
Closed

Better multi-user support for fig-home #73

klimkin opened this issue Mar 22, 2014 · 1 comment

Comments

@klimkin
Copy link

klimkin commented Mar 22, 2014

To optimize file transfer we tried using fig-home for multiple users. It works ok with setting group access properly, except the conflicts we get for tmp dir. The tmp dir is part of fig-home and is owned by user, which is currently performing operations on fig-home. If any files left in tmp, the next user will experience issues, since he won't be able to remove the other user's files.

There is a simple reason why there would be any files left in tmp - the fig process can be interrupted or killed by a user.

It must be easy to make the system less error-prone, if we use system tools for managing tmp directory. Those usually create unique tmp directory, which doesn't overlap with anything else. So if there are any leftovers, they will not block other user operations.

It would be interesting to consider using system TMP, which is normally maintained and cleaned by system. This would simplify management of leftovers in a long term. System TMP usually points to a local system disk. This can help resolving some issues having tmp on NFS for a price of loosing some performance (extra copy from local to NFS disk vs move on the same NFS disk).

@clonezone
Copy link
Collaborator

There are no plans to support multiple users using the same FIG_HOME due to permissions issues. Saving some disk space is not worth the code complexity.

The tmp directory in FIG_HOME is used instead of /tmp in order to avoid the problems of crossing file-system boundaries. This means that directory rearrangement inside of FIG_HOME after downloads/updates are as atomic as possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants