• Status Closed
  • Percent Complete
  • Task Type Bugs
  • Category Plugins
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by mlind - 2006-12-03
Last edited by jdgordon - 2008-08-10

FS#6410 - Plugin Disktidy error due to too many nested folders

Disktidy doesn’t finish it’s work, but stops with an error when it reaches a specific folder - where I have some Mac OS X apps placed (for portable use).

I moved the folder (containing the apps) up two levels to the root, and this time Disktidy worked as it should.
Moved folder back down one level and it still worked.
Moved folder 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)

Closed by  jdgordon
2008-08-10 12:46
Reason for closing:  Fixed

Same problem for me.
I have MSN Messenger for Mac on my iPod down one folder from root and I have this error when using Disktidy.

mlind commented on 2006-12-28 10:30

In the file “dir.c” there is a definition of the constant “MAX_OPEN_DIRS” and it’s set to 8.
Seems like a probable cause.
The plugin does not take heed of anything like this.
The plugin opens one directory and then makes a recursive call to the same function to open the next subfolder… Is this why it in RockBox is possible to browse down deeper than 8 subfolders but not with Disktidy?

mlind commented on 2006-12-28 10:51

OK. IRC seems to be the place to get answers… From IRC 10th of december:

[quote]20.32.53 #       * Bger just spotted that disktidy can’t enter more then 7 (or 8) 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

This also causes a problem when disktidy deletes a directory.
The return value of tidy_removedir() is not checked. If it runs out of handles while deleting a directory it will not delete the directory and will not show and error.

Interesting. I just discovered this on my F40 – once again the problem was due to deep directory structure in some portable applications.

What would be the proper solution to this? I’m interested in fixing Disktidy so it works as the user expects it to work.

I think it should continue looking in other directories instead of just quitting on the first error. I also think it should display a message at the end that some directories could not be deleted (or possibly a more descriptive message).

Should the plugin return with an error in case it can’t enter some directories, or should it still return success?

I attached a file that includes many clean-ups to the code (I made the application’s functions and variables static) and also some fixes for this too-deep directory issue.


Available keyboard shortcuts


Task Details

Task Editing