From: Archie C. <ar...@de...> - 2013-05-07 13:29:02
|
I guess the lack of response means there is no active effort to fix this bug. That's a real shame because this leads to filesystem corruption. I'd call that a pretty serious bug. Of course it's easy to just be a complainer :-) What can I do (if anything) to help? Dipping a toe here... would it not work to do the following: 1. Add a new FUSE supported flag -o sync_umount 2. Allow only the root user to utilize this flag; non-root users would get an EPERM error back 3. Make unmounts behave synchronously whenever -o sync_umount is used? -Archie On Tue, Apr 30, 2013 at 9:57 PM, Archie Cobbs <ar...@de...> wrote: > On Tue, Apr 30, 2013 at 9:22 PM, Nikolaus Rath <Nik...@ra...> wrote: > >> > It seems like correct would be that the unmount should not complete >> until >> > after fuse_op_destroy() returns >> >> Well known and agreed upon as being a bug, if I remember past >> discussions correctly. Just not easy to fix. >> >> >> http://search.gmane.org/?query=blocking+umount&group=gmane.comp.file-systems.fuse.devel >> > > Hmm... > > Next question: > > - What are the current plans for fixing this bug? > - Is there any workaround (doesn't look like it)? > > > -Archie > > -- > Archie L. Cobbs > -- Archie L. Cobbs |