Open thewacokid opened 6 years ago
Though this issue originally referred to a specific case of potentially orphaned trash objects, we are currently addressing the much broader circumstances that can result in orphaned objects and other trashing race conditions, so I thought this issue would be a good place to keep track of that. I am currently working on an implementation of marfs_unlink() via rename() and marfs_rename() via marfs_unlink() and hardlink creation which we believe will avoid all races/leakage associated with trashing. This implementation will require modifications to the marfs quota tool (to avoid counting trashed files against quotas, issue #211) and the marfs GC (to properly handle the new trash structure, issue #210).
The function that marfs_fuse calls to create MDFS infrastructure was pictured as (a first cut at ) a tool that would eventually serve some more-comprehensive admin tools. I figured we would long ago have found time to develop “marfs_admin” (or something) for creating new NS, new Repos, etc, but there was always some other task that seemed more urgent. I like to keep bringing up the idea, since it would go a long way toward easing administration.
One issue I recall is that we can’t infer what ownership and access, etc, should be given to associated directories and files. So, the admin tool would require some arguments to guide configuration, and instead, for now, there is some complicated grunt-work that must be done by hand.
On May 3, 2018, at 5:15 PM, David Bonnie notifications@github.com<mailto:notifications@github.com> wrote:
Just putting this here so we can follow up. If MarFS FUSE is never started, no trash directories are created for new namespaces (that pftool can write into, but aren't exposed via FUSE).
This leads to an interesting situation where you can delete files within the namespace but you can't trash the files first (on overwrite for example) so you end up creating orphan objects without any references. We should probably return an error if the unlink fails because the trash destination isn't accessible.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/mar-file-system/marfs/issues/203, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AH22-WpFwhlmBzvJtYRFL5-xN3P8lEtXks5tu4-CgaJpZM4Tx6xB.
Just putting this here so we can follow up. If MarFS FUSE is never started, no trash directories are created for new namespaces (that pftool can write into, but aren't exposed via FUSE).
This leads to an interesting situation where you can delete files within the namespace but you can't trash the files first (on overwrite for example) so you end up creating orphan objects without any references. We should probably return an error if the unlink fails because the trash destination isn't accessible.