tidy-folders extension package

I can't think you would want flatten and tidy-folders installed together. They seem mutually exclusive to my mind.
Yes - definitely should be a Conflicts: line in the control file for that one : )
 
I think to make this package suitable for inclusion in the main package repository it must at least only remove folders that contain only . files.

Done that.

It would actually be easier in Jim because the box has libraries that automatically determine the media root (different on the HD model).

It's easy enough to do in C as well. Both were supported in the first version.

The key point is that when it thinks a folder is eligible it removes the . files and then removes the folder. If in the meantime something has appeared in there then the subsequent rmdir call will fail (non empty directory error).

Done that as well, and fixed the packaging screw-up previously mentioned.

Latest version here:
<removed>

For anyone else's benefit, here's a quick guide on how to get it/install it:
1) telnet to your Humax box
2) cd /mod/tmp
3) wget <removed>
4) opkg install tidy-folders_1.0.1_mipsel.opk

You can remove it by
1) opkg remove tidy-folders
2) rm /mod/tmp/tidy-folders_1.0.1_mipsel.opk
or use the web interface to uninstall it.
 
I did look at the manual but couldn't find anything definitive.

Have now added this to the control file and re-uploaded.
 
I can't think you would want flatten and tidy-folders installed together. They seem mutually exclusive to my mind.

Maybe, but not .autoshrink or .autodecrypt, and who knows what other flags there may be in the future. I propose it is only valid to delete a folder if it only contains remnants that the Humax itself might have left behind, or alternatively ensure that it ignores folders starting "[".

Actually I see no reason flatten and tidy-folders couldn't be used together, it just wouldn't do very much in most circumstances. I don't see them as an actual conflict.

I guess it can do whatever you like as long as it is clear in the documentation what the consequences are and what potential conflicts there may be. I think we are suggesting refinements that make it have fewer consequences for a larger catchment of potential users, and having it delete to the recycle bin would add a layer of protection for anybody who did not understand the consequences.
 
Flags can be put back easily so that is of little concern and IMHO no reason to delete to the bin. If you don't want this auto-cleanup behaviour then don't install the package! Obviously it won't suit everybody.
It may not surprise you to find I have another extension called "auto-flags" which adds .autodecrypt and .autoshrink to any folders the machine creates automatically as a result of Series Link recordings!

Where does documentation go anyway? There seems to be nowhere for it in the package itself.
 
Oh, I see. So somebody with a dedicated folder they use to drop stuff into for shrinking will just have to remake it every time or not use tidy-folders. What's so wrong with using the recycle bin anyway? I'm not talking about what you might do or what I might do, but what would make it most useful to the wider community.
 
Oh, I see. So somebody with a dedicated folder they use to drop stuff into for shrinking will just have to remake it every time or not use tidy-folders. What's so wrong with using the recycle bin anyway? I'm not talking about what you might do or what I might do, but what would make it most useful to the wider community.

It doesn't remove any folder whose name starts with a '[' or a '.' - I think this is a reasonable compromise, and should satisfy the wider community.
You already suggested names starting with '[' be somehow special, so I took it on board.
 
Updated this to stop it removing any folder beginning with '_' and also added proper logging that you can see via the Web-If's Diag page.

Code:
humax# opkg install <removed>
 
Back
Top