Ignore hidden/special files?

Get help. Get answers. Let others lend you a hand.

Moderator: Mr_Noodle

Ignore hidden/special files? Tue Sep 12, 2006 9:34 pm • by cjohnson
I have a Hazel rule to tidy up my downloads folder. It moves anything older than a few days into a subfolder called "Archive".

I have noticed two problems. First, I noticed that the custom icon on my Downloads folder disappears. Checking the console.log, I realized this was because it moved the hidden file "Icon" into the subdirectory. Is there anything I can add to the rules to ignore any hidden/system files?

Second, Hazel keeps trying to move the Archive directory into the Archive directory (a circular reference). I have worked around this by adding another clause to the rule (where name is not "Archive"), but I think it would make sense for Hazel to automatically exclude the destination folder as an argument for any Move operations.

Any help would be appreciated!
-chad
cjohnson
 
Posts: 2
Joined: Tue Sep 12, 2006 9:27 pm

Re: Ignore hidden/special files? Tue Sep 12, 2006 11:26 pm • by Mr_Noodle
cjohnson wrote: First, I noticed that the custom icon on my Downloads folder disappears. Checking the console.log, I realized this was because it moved the hidden file "Icon" into the subdirectory. Is there anything I can add to the rules to ignore any hidden/system files?


You can set up a rule (make it first in the list) that matches the Icon file and set the action to "Ignore file". Since the first rule to match gets applied, this will catch the files before any of the other rules get a crack at it. You can also exempt the file on a specific rule by just adding a condition like "Name is not 'Icon'".

Nonetheless, the Icon file is a common case. I'd have to think about it but I may consider always having Hazel always ignore the Icon file unless I can come up with a case where someone would want to apply rules to it.

Second, Hazel keeps trying to move the Archive directory into the Archive directory (a circular reference). I have worked around this by adding another clause to the rule (where name is not "Archive"), but I think it would make sense for Hazel to automatically exclude the destination folder as an argument for any Move operations.


The problem here is that when you create a rule, Hazel does not know ahead of time what files will match it until it actually runs. So, it can't prevent you from choosing a folder that may not make sense later on down the line. Plus, in your case, the argument of the move operation does make sense for every file except for the "Archive" folder. It shouldn't prevent you from selecting "Archive" as a destination just because the folder exists in the same folder. Sorry if this is getting a bit hard to follow but that tends to happen when you get into these more conceptual discussions.

In the future, I may consider putting in an analysis engine for rules but it would be imperfect. In the end, though, it's up to you to make sure the rules make sense.
Mr_Noodle
Site Admin
 
Posts: 8427
Joined: Sun Sep 03, 2006 1:30 am
Location: New York City

Wed Sep 13, 2006 12:06 am • by cjohnson
Thanks for the tip. I think you are right that these problems can be solved with some simple rules. Just a little fine tuning... ; )

By the way, the Icon file appears to have a special character at the end of it. The 'ls -l' command displays it with a ? at the end, like "Icon?", and the console.log printed it with something like a carriage return or newline when it moved it. This might help you parse it out more accurately.

-chad
cjohnson
 
Posts: 2
Joined: Tue Sep 12, 2006 9:27 pm

Wed Sep 13, 2006 10:35 am • by Mr_Noodle
Yeah, the icon file has a carriage return at the end.

I'm going to fix it so Hazel ignores any invisible files (including the icon). It should be in the next maintenance release which I'm planning to release within the next week. Until then, I'd say add a condition like "Name starts with Icon". It will catch any files beginning with the word "Icon" but it's a temporary measure until I get the fix out.

Thanks for finding that.
Mr_Noodle
Site Admin
 
Posts: 8427
Joined: Sun Sep 03, 2006 1:30 am
Location: New York City

Wed Sep 13, 2006 11:04 am • by dbingham
I just wanted to clarify. This may be known already, but it is actually a carriage return (ASCII code 0x0d) followed by a new line (ASCII code 0x0a).

You can take a look at it in detail by doing the following in Terminal:
Code: Select all
$ ls Icon* | od -x

for the hex values, and:
Code: Select all
$ ls Icon* | od -a

for the named characters.

Obviously those commands must be run in a directory that has a custom icon.

It may also be worth noting that not ALL hidden files should be ignored since OS X honors the *nix convention of a dot preceding the name as a hidden file. Often, I keep things in various places as a "dot" file so they don't show up in a simple finder window, but I might still want to manage them with a rule for disk space management. Just a thought.

Maybe the rule should be special, OS maintained files get ignored. Like Icon files and .DS_Store files. Similar concept to what various clean archivers and unmounters do for making things work nicely with Windows. That way user content remains valid for rules even if it is hidden.
dbingham
 
Posts: 7
Joined: Wed Sep 13, 2006 10:52 am

Wed Sep 13, 2006 7:30 pm • by Mr_Noodle
Thanks for the pointer but I figured out it was a carriage return. 'ls' would show a question mark but if I did a 'ls Icon' then hit tab (for file completion) it showed the full name ('Icon^M'). In the end, though, it's all academic as the icon file has its invisible bit set.

Could you give me examples of what kind of dot files you would want processed? I was planning to ignore all dot files but if you can give me cases where you'd not want them ignored, let me know.

As far as OS maintained dot files, here's the list I've come up with:
.DS_Store
.Spotlight-V100
.hidden
.hotfiles.btree
.vol
.Trash (in case someone monitors their home folder?)
.Trashes (in case someone monitors the root of a mounted volume?)

Let me know if there are any I've missed.
Mr_Noodle
Site Admin
 
Posts: 8427
Joined: Sun Sep 03, 2006 1:30 am
Location: New York City

Wed Sep 13, 2006 10:04 pm • by dbingham
Glad you already figured it out. I didn't know if you'd be doing an exact match on a string. If so, I thought it might be important that it was actually CR & NL not just CR (i.e. a Windows line ending rather than the classic Mac line ending). However, sounds like you are checking for it some other way, so no biggie.

Well, the first example I can think of for being able to match dot files is the following:

I keep a text file with a list of all applications I have on my machine. It is automatically updated when I install a new app via a small tool I wrote myself. I keep this file in my Documents folder as a hidden file (using the "dot" method). I keep it hidden so that I can keep the top level of the Documents folder looking clean in Finder, and because I don't need to interract with it on a daily basis (only really need it to restore). There are a number of situations that might come up where I'd want my installed apps log to be matched in a rule. Say for example, I want to move it to another folder once a month so that I can keep track of which apps I installed in which month.

I don't actually do that, but it is one example of what I *might* want to do. In general it just feels a little overzealous to exclude all hidden files when users have the ability to make their own files hidden.

As for your list of OS controlled files, seems like a pretty good list to me. More than I would have come up with. =)
dbingham
 
Posts: 7
Joined: Wed Sep 13, 2006 10:52 am

Fri Sep 15, 2006 1:15 am • by Mr_Noodle
Fair enough.

Actually, from my check of all the system dot files, it seems like they also have their invisible bit set so I'll just only check that for now and leave regular, non-invisible dot files to be processed. Expect the next maintenance release on Monday.

Thanks.
Mr_Noodle
Site Admin
 
Posts: 8427
Joined: Sun Sep 03, 2006 1:30 am
Location: New York City

Wed Sep 20, 2006 11:33 am • by dbingham
Mr_Noodle wrote:Fair enough.

Actually, from my check of all the system dot files, it seems like they also have their invisible bit set so I'll just only check that for now and leave regular, non-invisible dot files to be processed. Expect the next maintenance release on Monday.

Thanks.


Just pulled the update. Looks great and seems to work exactly as I'd expect.

Thanks!

-dbingham
dbingham
 
Posts: 7
Joined: Wed Sep 13, 2006 10:52 am


Return to Support