unlocking hidden directories and beyond

A bit of background:

I discovered that the mounted volume of DMG archives of software distributions created on Leopard (which I'm not using yet; still @10.4.10) often (always?) contains a locked/hidden/empty .HFS+ Private Directory Data^M (yep, that's a trailing control-M) directory in its root, possibly a leftover from the FSEvents daemon since there's also a .fseventsd directory there. When copying the root directory from the mounted volume the locked directory comes along with it, which has unwanted side effects such as not being able to expunge Trash while it contains the locked directory.

Enter Hazel:

I'd like to construct rules/actions to unlock those .HFS+* droppings. So far I've managed to get HazelÃ‚Â monitoring my ~/.Trash folder using a single rule with a "Kind is Folder" condition and "Run rules on folder contents", "Run Shell script <name>" actions. The script is essentially this one-liner:

Code: Select all: find . -name '.HFS+ Private Directory Data*' -exec SetFile -a l {} \;

The file path argument passed to it is unused.

This seems to work okay but since I'm not satisfied with this as a long-term solution I'm soliciting suggestions for ways to optimize both the script and how Hazel invokes itÃ¢â‚¬Â¦ or replace itÃ‚Â with something more elegant, which leads into:

One issue is that Hazel doesn't seem capable of matching dotfiles directly. A lesser one is no built-in (un)lock action which would eliminate need for a script. Lastly, there's no way to specific (AFAIK) the single Trash "pseudo-folder" that includes trash folders from other volumes.

A more ambitious project is to get rid of that locked .HFS+* directory whenever it shows up where it doesn't belong because it causes trouble when moving the parent folder or replacing a folder that already contains it. I don't mind quarantining where the first instance of .HFS+* will be when its copied from a mounted dmg volume, letting Hazel do unlocking/deleting there and superseding the need for the Trash unlocking method. I just started with the latter because it was easier/safer with my current lack of experience with Hazel.

Hopefully that makes sense and covers all the relevant details. Thanks in advance for any suggestions!

Hazel ignores invisible and hidden files. This was a conscious design decision over time as users were confused whenever files they didn't know existed were being manipulated. Also, since most hidden files are specific to the directory they are in, there were cases of unwanted side effects when they got moved because of some rule.

I'll have to say that I'm not inclined to add a lock/unlock action as I feel that it's a bit esoteric and also because I don't want to encourage more usage of the lock flag which seems to cause more problems than its worth with users. I haven't investigated the .HFS+... files but if they are locked, then you may want to file a bug report with Apple as I feel it's a bad idea to do that on files that are very likely to be thrown away by users. I feel this is a case where it would be better to fix things at the source.

Mr_Noodle wrote:Hazel ignores invisible and hidden files. This was a conscious design decision over time as users were confused whenever files they didn't know existed were being manipulated.

Yeah, that seems reasonable.

Also, since most hidden files are specific to the directory they are in, there were cases of unwanted side effects when they got moved because of some rule.

Not sure I understand how that might happen. Got a simple example?

I'll have to say that I'm not inclined to add a lock/unlock action as I feel that it's a bit esoteric and also because I don't want to encourage more usage of the lock flag which seems to cause more problems than its worth with users.

Would be useful if this category of features could be added and enabled with a defaults write com.noodlesoft.Hazel esoteric -bool YES command. However Ã¢â‚¬Â¦

I haven't investigated the .HFS+... files but if they are locked, then you may want to file a bug report with Apple as I feel it's a bad idea to do that on files that are very likely to be thrown away by users. I feel this is a case where it would be better to fix things at the source.

I agree this specific case should really be Apple's problem; I'll submit a bug report.

Got any suggestions for optimizing my script or going about the unlocking another way without any Hazel changes? It's overaggressive when relatively large folder hierarchies get dumped to ~/.Trash. And I've noticed unpredictable "File <name> is busy" messages in the log, like:

2007-11-06 11:19:43.877 hazelfolderwatch[1045] File .DS_Store is busy. Skipping for now.

Ã¢â‚¬Â¦ apparently triggered by the Trash rule. Not really a big deal for this but if it were some other folder I might be more concerned with what's happening.

An example dot file would be the .DS_Store file. It is location specific so moving that anywhere else can cause odd effects (for example, Finder comments are stored in there).

The busy messages do happen every now and then. I'd only be concerned if a file is considered busy for way too long. In such a case, then a flag was mis-set (either the busy or locked flags).

As for your script, I'm not exactly sure what you mean by Hazel being "overaggressive," but I would say it might make more sense just to use cron or iCal to deal with it. You can set it on a less frequent schedule if you don't want it to run often.

Mr_Noodle wrote:An example dot file would be the .DS_Store file. It is location specific so moving that anywhere else can cause odd effects (for example, Finder comments are stored in there).

Seems what you're saying is that by allowing Hazel to directly access hidden/dot files it might cause rules to unintentionally match (e.g. with a wildcard) and move ones that are intended to be manipulated in other specific ways. In my case I'd just be interested in explicit cases that would avoid accidental matches/moves with unwanted side effects, but I can understand (and begrudgingly accept

) your decision not to implement this.

The busy messages do happen every now and then. I'd only be concerned if a file is considered busy for way too long. In such a case, then a flag was mis-set (either the busy or locked flags).

I'm not sure how to tell if it's busy for "way too long" with the ~/.Trash/.DS_Store file. And I'm curious why an invisible file is even being reported by Hazel in the first placeÃ¢â‚¬Â¦ it's kind of a "here I am, but you can't touch me!" tease.

As for your script, I'm not exactly sure what you mean by Hazel being "overaggressive," but I would say it might make more sense just to use cron or iCal to deal with it. You can set it on a less frequent schedule if you don't want it to run often.

Any of that is opposite of the relatively frequent checking I want to do so the locked folder will be unlocked if I want to empty Trash shortly after the folder's put there.

What I mean by "overaggressive" is that Hazel was unnecessarily traversing the ~/.Trash hierarchy. I've dealt with it by optimizing the script a bit with "-maxdepth 2 -type d":

Code: Select all: find . -maxdepth 2 -type d -name '.HFS+ Private Directory Data*' -exec SetFile -a l {} \;

Ã¢â‚¬Â¦ and removing the ""Run rules on folder contents" action in Hazel. This works fine because the hidden folder will normally be in the root of folders being trashing. If one got buried deeper for some reason I'd just move the folder to top-level of Trash and Hazel would unlock it there, as usual.

There's one thing still missing, mentioned in my original post, that would be useful for this and other Trash-related tasks with Hazel:

there's no way to specific (AFAIK) the single Trash "pseudo-folder" that includes trash folders from other volumes.

There's the Trash tab in Hazel's Preference Pane that I assume (haven't checked) is the union of all trash locations, like opening Trash in Finder. What I'd like is that unified Finder-like Trash available as a special folder under the Folders tab, if that's possible. Thanks!

Actually, it is odd that the .DS_Store file is being registered as busy. I'll have to take a look at it but it could also be a case where the trash is treated a bit differently than regular folders.

I also have on my list the notion of having a depth/level attribute to filter on to limit folder traversals. No ETA yet but it's being considered.

I'll also consider the Trash "pseudo-folder". I wanted to keep the trash management simple but I'll think about exposing a more official way of creating rules for trash. If it happens it will probably be a special folder in the "Quick Folders" pull down when you add a folder. I'd have to work out the order in which rules are processed in relation to the trash options (do I run rules first or check the trash size?).

Thanks for the suggestions.

Sounds good. Thanks for the followup.