disktidy.config entry to delete ##MUSIC# folder (Clip+)?

[grums]

The Clip+ adds folders when using the OF, they're empty and take up space in the Files browser when RB is booted afterwards.

I've tried to configure Disktidy to remove those folders - disktidy.config:
< Other >: no
    AUDIBLE/: no
    AUDIOBOOKS/: no
    PODCASTS/: no
    RECORD/: no
    MUSIC/: no
    *MUSIC#/: no
    *PORT#/: no

The last 2 lines don't match the ##MUSIC# & ##PORT# folders, and of cause I cant specify:
    ##MUSIC#/: no
    ##PORT#/: no
- because '#' at the start is a comment?!

What's the trick? (I know I can delete them manually, but...)

Ole

[fml2]

How can you tell they don't match? Did you mark those folders for deletion? You can try to create a dummy folder without # in the name and delete it via the plugin. Then you can see if it's really because of the 'strange' folder names.

[grums]

I have tried that:

The plugin works OK on folders and files - as long as the don't have # as the first character of the name.
If I put a filename like #XYZ in the configuration file it will disappear (parsed away because it's considered to be a comment).
And I've now found out (plugin doc!) that * only matches in the end of a name.

I'm struggling to have a development system up and running - and hoping that a/the Disktidy developer might see this?

Ole

Post Merge: February 17, 2011, 09:37:41 AMSorry, I posted the last instead of Preview...

A possible modification could be to define an escape character which will be parsed in as part of the name (eg. \##MUSIC#/) and let the plugin throw it away.
That would be quite simple (I guess).

The character chosen should be one that is not parsed away and not allowed in file/foldernames in Rockbox - any suggestions?

Ole

[Chronon]

Your use of backslash seems natural.  It should be free since it can't appear as a part of a path in Rockbox.

[[Saint]]

And I've now found out (plugin doc!) that * only matches in the end of a name.

Where did you read this?

It should be changed as this has not the case since some time now.

Example:

*.<ext>

and

start_of_filename*.<ext>

or

*end_of_filename.<ext>

Will all work correctly.


For you:

Code: [Select]

< Other >: no
    *MUSIC#/: no
    *PORT#/: no

Should do what you want it to do.



[St.]

[grums]

I read about the wildcard in Disktidy plugin doc here:
http://www.rockbox.org/wiki/PluginDiskTidy

I'm running the latest stable release, and the * is working as described: at the end of a name.

Ole

Post Merge: February 18, 2011, 02:05:29 AMJust tried it in the r29317 Windows simulator: Rockbox simply exits when Disktidy is set to tidy using the *MUSIC#/ pattern...

Ole

Post Merge: February 18, 2011, 02:07:11 AMI'm quite new to this - where's the newest hot Disktidy source (link)?

Ole

[fml2]

What do you mean exactly when you say "exits"? Just does nothing (deletes nothing), quits the plugin and returns to "main" Rockbox? Or does it crash? Or what? Could you be more specific?

Can it be that the folder is not deleted because it is hidden (as in a FAT file attribute)? It may be shown in your PC's file browser, but IIRC Rockbox ignores hidden files and folders.

The neweset hottest disktidy source is at http://svn.rockbox.org/viewvc.cgi/trunk/apps/plugins/disktidy.c?view=markup

[grums]

Exits (as if I had closed the window using the X icon).

The Simulator window disappears a few seconds after having activated cleanup, and Windows shows no sign of it being active anymore.
The 3.7 release build of the simulator runs OK - but has the # problem.

The ##MUSIC# folder has the same attributes as the other folders the Clip+ creates when files are uploaded (not hidden) - and they get wiped OK.

Thanks for the link.

Ole

[fml2]

Then it's probably a crash which need investigation. If I only had time...
Post Merge: February 18, 2011, 04:14:37 PMI tried to investigate the case. I compiled the current version of H120 simulator, and it crashed. I think it's not because of the folder name (##MUSIC#) since it also crashed when I tried to clean e.g. Linux files. I got many messages "SDL_WaitEvent error" and then a segmentation fault. I didn't do anything further since I had other things to do.