Page 1 of 1

Possible "Date Added" Bug

PostPosted: Mon Nov 27, 2006 9:08 pm
by njr
I've recently tried to use Hazel to implement a kind of psuedo-"Tickler File" (if anyone is familiar with the idea from GTD). Basically, it's place to throw things out of my Inbox for a certain amount of time with assurance that the'll come to my attention again later. Here's how it works:

1. I manually move things from the "Inbox" folder to the "Tickle" folder.

2. The "Tickle" folder uses a simple rule: If Date Added is not in the last 3 days, then move the file to the "Inbox" folder.

3. After 3 days, the rule takes effect, and files bounce back to the Inbox.

The problem is that if I put a file back into the "Tickle" folder, it immediately bounces back out, as Hazel seems to re-evaluate the rule based on the original Date Added.

I wasn't sure if this was a bug or a feature until I noticed if I open the files and re-save them, *some* of them bounce back out and some don't. The ones that do are plain text files. The ones that don't are OmniOutliner files. The difference is that OmniOutliner files are bundles/packages, so the FileID changes when they're saved. To Hazel, as of 1.1.2, they're completely different files. (For testing purposes: TextEdit RTFD / "RTF with Images" files are packages, too, and are similarly affected.)

Off the top of my head it seems like all that is needed is for Hazel to re-record the Date Added, but I don't know what other effects that might have. I can think of some ways to work around this with rules, but it seems like a bug, so I thought I'd post it here so Mr. Noodle can look into it.

--Nick

PostPosted: Tue Nov 28, 2006 1:53 pm
by Mr_Noodle
Hi Nick,

This is one of those cases where I did something a certain way for a reason and when I changed it, I forgot what that original reason was and ended up breaking it. In this case, in tweaking the internal db stuff, I broke correlating files based on name which is needed for apps that, when saving, write out a new file every time.

So yes, I need to fix it by correlating the file by name under certain circumstances and copying the metadata for it over so that it appears as the same file to Hazel. I'll work it into the next maintenance release (which will hopefully be out in the next week or so).

Thanks for catching that.

Also, I encourage you to post your GTD hints to the tips forum.

PostPosted: Wed Nov 29, 2006 6:44 pm
by Mr_Noodle
Hi Nick, I've got a question for you.

You say that files are being bounced back immediately. Is it the case that the file in question had already been in the "Tickle" folder for 3 days, was moved out by Hazel and then you manually moved it back into the "Tickle" folder? Or are you saying it is being bounced out the first time?

In any case, working on the issue with saving files (basically, I'm reverting things back to using names instead of ID's but looking into adding something to deal with renames of files). But let me know about the above as that seems like a different bug.

Thanks.

PostPosted: Thu Nov 30, 2006 1:48 am
by njr
Yeah, the immediate bounce happens when I add a file to the folder a second time.

On a hunch, I tested what happens when I add a file to a folder with a Date Added rule, remove it manually, and then re-add the file after the rule would have triggered. The same thing happens; the rule is triggered based on the first time it was added. (In retrospect this seems obvious, but it took me a while to figure out what was going on.)

Thanks for a really great product, by the way.

-Nick

PostPosted: Thu Nov 30, 2006 12:08 pm
by Mr_Noodle
Ah. I think I know what is happening then. Basically, Hazel keeps track of a file for some period after it is moved/removed to detect loops. The problem is that it should remove the date added and force it to be re-calculated every time it's moved. Expect a fix for this (and the other problem) next week.

Thanks.