Re: [fuse-devel] Rmdir via GUI = recursive through virtual folders

[Karel M. <kar...@gm...>]

On 16 Apr 2009, at 11:37, Sven Utcke wrote:

> Hello Karel,
>
>> I did come up with an alternative way. By adding another special
>> folder: +REMOVE_FOLDER, I can do a mv folderToDelete  
>> +REMOVE_FOLDER. I
>> can than catch this action in the rename() and do the removal. Rmdir
>> would be disabled completely. This isn't an ideal way of doing things
>> either. For example if an application tries to execute an rmdir it
>> wouldn't work.
>
> Hmm.  Note quite sure if this will work with all rm-szenarios, but
> what about having the first folder returned by readdir() be a special
> folder, which, if removed, will take all the other virtual folders
> with it?  Any szenarios where that would fail?

That's a really interesting idea Sven. I just tried it out on an older  
version of my filesystem (I'm currently rewriting some parts and it's  
not working yet) and it is a good option for the most part (see below).

As it might be interesting for someone else I'll describe here what (I  
think) happens when rm -r is executed from the terminal:

1) getattr(/to/remove)
2) readdir(/to/remove)
	At this point I return a list of files/folders:
	[.+RMDIR, +FIND, +ADD, +REMOVE, realfolder].
	Notice how I put the RMDIR at the top of the list, this is very  
important.
3) getattr(/to/remove/item) for each returned result
	This happens in the same order as items are in the returned list.
4) readdir(/to/remove/.+RMDIR)
	A readdir of the first directory of the list.
5) getattr(/to/remove/.+RMDIR)
6) rmdir(/to/remove/.+RMDIR)
	The RMDIR is removed first.
	I put /to/remove in a to_remove list of folders.
7) readdir(/to/remove/+FIND)
	Because /to/remove is in the to_remove list, this returns nothing
8) getattr(/to/remove/+FIND)
9) rmdir(/to/remove/+FIND)
	This does nothing
10) Step 7-9 is repeated for every result of step 2
11) getattr(/to/remove)
12) rmdir(/to/remove)
	This indicates the end of the removal.
	I remove /to/remove from the to_remove list.

There is however a difference when using the GUI. The GUI doesn't do a  
rmdir directly after step 5. It first does a readdir() for the other  
folders returned by step 2. So what this means is that in order to let  
the readdir() for special folders return an empty folder, /to/remove  
has to be added to the to_remove list when the readdir(/to/remove/. 
+RMDIR) takes place. So this brings a problem: whenever a readdir() of  
a RMDIR folder is done, the parent folder will be added to the  
to_remove list, even though it might just be an ls in terminal.
As I use a hidden folder, this isn't THAT dramatic. And while I can  
imagine a find command giving the same problem, this kind of command  
shouldn't be used at all because of the infinite depth of the path  
(due to tags)...

Another problem is that when a removal action is stopped by the user, / 
to/remove will still be in the to_remove list.

Oh well, I suppose I'll simply have to make some tradeoffs...

Note: I did all this testing using OS X Leopard and MacFuse, I haven't  
tested it under Linux yet (I have an ubuntu install).

Greetings,

Karel