HAZEL STRANGE BEHAVIOR

Hi, we are experiencing some strange behavior with this hazel rule:

2009-11-25 19:09:04.794 hazelfolderwatch[48772] DEBUG: New rule signature. Executing actions.
Old signature: (null)
New Signature:{(NOT dateAdded hazelIsInTheLast: 1296000) AND (NOT dateModified hazelIsInTheLast: 1296000) AND (NOT dateCreated hazelIsInTheLast: 1296000) AND (NOT typeObject isType: "public.folder")}:{(move:/Users/administrator/.Trash,{
"Replace Existing" = 0;
"Throw Away Dupes" = 0;
})}
2009-11-25 19:09:04.836 hazelfolderwatch[48772] [File Event] File moved: indiana.mov moved from folder /Volumes/XSAN_DIGITION/Miquel Àngel/DOWN VESPRE/PROJECTE VW ESTRENES to folder /Volumes/XSAN_DIGITION/.Trashes/501.
2009-11-25 19:09:04.836 hazelfolderwatch[48772] DEBUG: Action changed file: indiana.mov

We want to delete files older than 15 days, but with some files like this, are deleted instantly at the moment we put on the folder.

We are monitoring with Hazel a network folder, and all users drop files inside it from different machines.

Is there any way to check the file date of hazel's database?

The folder has a large amount of files, 6 TB aprox. Only a few files are behaving this way.

Thank you for your support,
Kind regards, and I wait for any clue.

You can check the date created and date modified of a file by selecting it and going "Get Info" in Finder. Date added is set by Hazel when you add it to that folder so I'm surprised it would move it right away since that condition by itself should prevent the rule from running if you did just drop that file in.

Also, you can use the preview function to test this without having to go through the trouble of having Hazel throw away files you don't want it to (just stop Hazel and use the preview until you are happy with how it works).

You can also try testing this out on a folder on a local drive. Maybe there's some issue with the network drive and its reporting of dates. What network file protocol are you using for this?

You can check the date created and date modified of a file by selecting it and going "Get Info" in Finder. Date added is set by Hazel when you add it to that folder so I'm surprised it would move it right away since that condition by itself should prevent the rule from running if you did just drop that file in.

The creation and modifing date of the files was correct, the file was created and modified yesterday, can be an issue with the regional configuration of the date?

We are spanish people our date format is "day/month/year" in our client workstations, and our Xserve is configured with english format date "month/day/year".

Also, you can use the preview function to test this without having to go through the trouble of having Hazel throw away files you don't want it to (just stop Hazel and use the preview until you are happy with how it works).

Our preview test seems to work correctly always. It's difficult to us to find the problematic files because its a 6 TB Volume with amount of files and folders. When we run hazel is easy to see the problematic files in trash because we change the file color to red two days before the deletion. And problematic files are not tinted.

You can also try testing this out on a folder on a local drive. Maybe there's some issue with the network drive and its reporting of dates. What network file protocol are you using for this?

Is an XSAN volume mounted locally on all the servers and Workstations, the last two conditions (creation date and modifying date) were added when we detected this problem with a few files, to be more accurate with the dates but the problem persist.

Thank you for your fast answer.
Best Regards.

Today test confirm that the problem persist this is the log:

Code: Select all: meteo 16:9-FIN-000005f0: Rule Esborrar_fitxers matched. 2009-11-26 17:32:15.483 hazelfolderwatch[1715] DEBUG: New rule signature. Executing actions. Old signature: (null) New Signature:{(NOT dateAdded hazelIsInTheLast: 1296000) AND (NOT dateModified hazelIsInTheLast: 1296000) AND (NOT dateCreated hazelIsInTheLast: 1296000) AND (NOT typeObject isType: "public.folder")}:{(move:/Users/administrator/.Trash,{ "Replace Existing" = 0; "Throw Away Dupes" = 0; })} 2009-11-26 17:32:15.496 hazelfolderwatch[1715] [File Event] File moved: meteo 16:9-FIN-000005f0 moved from folder /Volumes/XSAN_DIGITION/Informatius/save arxius/Render Files/meteo plantilla 16:9 to folder /Volumes/XSAN_DIGITION/.Trashes/501. 2009-11-26 17:32:15.496 hazelfolderwatch[1715] DEBUG: Action changed file: meteo 16:9-FIN-000005f0

Checking Trashed file with mdls we obtain:

Code: Select all: mdls /Volumes/XSAN_DIGITION/.Trashes/501/meteo\ 16:9-FIN-000005f0 kMDItemContentCreationDate = 2009-11-26 17:32:18 +0100 kMDItemContentModificationDate = 2009-11-26 17:32:22 +0100 kMDItemContentType = "com.apple.quicktime-movie" kMDItemContentTypeTree = ( "com.apple.quicktime-movie", "public.movie", "public.audiovisual-content", "public.data", "public.item", "public.content" ) kMDItemDisplayName = "meteo 16/9-FIN-000005f0" kMDItemFSContentChangeDate = 2009-11-26 17:32:36 +0100 kMDItemFSCreationDate = 2009-11-26 17:32:18 +0100 kMDItemFSCreatorCode = "KeyG" kMDItemFSFinderFlags = 0 kMDItemFSHasCustomIcon = 0 kMDItemFSInvisible = 0 kMDItemFSIsExtensionHidden = 0 kMDItemFSIsStationery = 0 kMDItemFSLabel = 0 kMDItemFSName = "meteo 16/9-FIN-000005f0" kMDItemFSNodeCount = 0 kMDItemFSOwnerGroupID = 1002 kMDItemFSOwnerUserID = 570 kMDItemFSSize = 35141977 kMDItemFSTypeCode = "MooV" kMDItemKind = "QuickTime Movie" kMDItemLastUsedDate = 2009-11-26 17:31:44 +0100 kMDItemUsedDates = ( 2009-11-26 00:00:00 +0100 )

I advice that file was being created at the moment that hazel was running.
Is there any problem with hazel when the files is created or dropped to a folder?
Thank's for your support.

It is perplexing. Does it happen consistently with certain files? If so, could you send them to me (zip them up to preserve any timestamps)? Also, I suggest trying on the machine's boot drive to eliminate the XSan as a problem.

The creation and modification times by themselves should prevent the rule from matching so I don't know what's going on here. I'll see if anything else comes to mind but let me know if you dig up anything else.