Disktidy: "Plugin returned an error"

[mlind]

Disktidy doesn't finish it's work, but stops with an error when it gets to a certain point in the file structure.

I THINK it is when it reaches a folder where I have some Mac OS X apps placed for portable use.
Could there be an issue with how many levels of nested folders are possible?

[perfectdrug]

i experienced the same and i also think it is because it's too deep in the filestructure
when i delete the folder with the subfolders disctidy finish as normal

[mlind]

Yes!

I moved the folder (containing the apps) up two levels to the root, and it worked!
Moved it back down one level and it still worked.
Moved it back down yet another - to it's original position - an got an error.

Seems you cannot have more than 7 levels of sub-folders.
(5 of my 8 were inside the app structure)

Thanks Perfectdrug for helping me in the right direction.
/M

[mlind]

Can someone confirm that

Code: [Select]

#define MAX_OPEN_DIRS 8

(found in "dir.c")
means that the afforementioned problem is not with the plugin (Disctidy) but a system limit?
- which means we can't do anything about it...

And why 8? Any specific reason?

[mlind]

OK. IRC seems to be the place to get answers...
From IRC 10th of december:
http://www.rockbox.org/irc/rockbox-20061210.txt

20.32.53 #       * Bger just spotted that disktidy can't enter more then 7 (or levels in the dir tree
20.33.39 #       Bger> (because it doesn't close the dir handle and #define MAX_OPEN_DIRS 8 )
...
20.39.56 #       amiconn> But you cannot close the parent handles, otherwise recursion won't work

[mlind]

I managed to fix this myself!
 
At last I got myself a working coding environment!
And with some coding I made the plugin avoid going deeper than allowed, but still carry on with the rest.

Here's my experimental patch:
http://www.rockbox.org/tracker/task/6512

How do I edit "related tasks" / dependencies on FS?

[the_winch]

Please test this patch.

http://www.rockbox.org/tracker/task/6514

It keeps track of the position in the directory so the handle can be closed when recursing into a sub dir and then reopened afterwards.
It will run a little slower due to reopening dir handles and skipping over already processed items.
This removes the directory handle limit but the next limit is the stack, if the dir tree is too deep you will get a stack overflow.

There is a h120 build with the patch applied here
http://winch.pinkbile.com/temp/h120.zip

[mlind]

next limit is the stack, if the dir tree is too deep you will get a stack overflow.

I got:

Code: [Select]

*PANIC*
Stkov main

Seems it managed to clean 8 but not 9.
But for my original actual case, before I put things even deeper for testing, it is just enough to be ok.

In my case I really don't think it's such a big deal if the deepest folders don't get cleaned.
It's no place I will go browsing for music.

But a possible sollution would maybe be to let Disktidy start with the current folder (in the browser) and clean the 8 allowed but no further down. If the user wants his one deep folder to be cleaned he can browse there and Disktidy will that folder and its contents?