You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
The text was updated successfully, but these errors were encountered:
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.
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).
The text was updated successfully, but these errors were encountered: