parent folder as pattern input data?

I'm wondering if the name of a file's parent folder might be used to create patterns for renaming or moving files. I realize this seems silly since if a file is already in a directory of a certain name, why do I need to move it to a directory of that name?

The reason is that I'm trying to figure out some way of specifying an arbitrary string on a file to be used for sorting it and I can't think of a better way than using the name of a parent folder. To give an example, I'd like to sort my folders by:

year > month > creator's name

I was thinking that I would have Hazel monitor a folder full of empty folders with different names of creators. I would drop some files into one of these folders, and Hazel would move them to a different folder entirely (where the files are actually kept) and sort them down by year, month, and the enclosing folder name (which it's about to be moved out of).

Incidentally, it would also be nice to allow the OpenMeta action to use patterns such that I could add the creator's name as an OpenMeta tag as well. (Or conversely, I suppose if you allowed OpenMeta tags to be used in patterns, then I could change this whole scheme.... hm)

What type of file are you trying to find the creator for? Have you checked metadata to see if the userid or login is stored by the saving program?

If I were in your boat, I would consider filename keywords. You would rename the file with the author and hazel would do its thing.

a_freyer wrote:What type of file are you trying to find the creator for? Have you checked metadata to see if the userid or login is stored by the saving program?

It's purely a user (ie. me) assigned creator -- it's not going to be on the file itself. That's why I want to be able to specify it in some way to Hazel, and I was thinking that enclosing folder would be the cleanest way.

a_freyer wrote:If I were in your boat, I would consider filename keywords. You would rename the file with the author and hazel would do its thing.

Ew, I really don't want to clutter my filenames with the creator's name. Metadata belongs either in your folder heirarchy or something like OpenMeta (or both).

I have on the feature list the addition of an attribute for the parent folder in rename/subfolder patterns. There are two forms of this though: just the parent folder name and the relative path of the parent.

In the second case, let's say you are monitoring /some/path/to/folder and the file you are processing is in /some/path/to/folder/in/a/subfolder. The relative path would be in/a/subfolder (it's the parent path up to the top level folder). It seems weird but it would be useful in cases where you wanted to mirror the folder hierarchy somewhere else.

So, for now, you might have to do something a tad messy but the feature is being considered for a future release.

Mr_Noodle wrote:In the second case, let's say you are monitoring /some/path/to/folder and the file you are processing is in /some/path/to/folder/in/a/subfolder. The relative path would be in/a/subfolder (it's the parent path up to the top level folder). It seems weird but it would be useful in cases where you wanted to mirror the folder hierarchy somewhere else.

Oh, I would find that relative path functionality really handy indeed. I was actually thinking about that, but thought it would be too much to ask. I assume each of the subfolders would be available as a separate pattern item? With that, I could (in addition to the mirroring you mention) do things like convert complex folder-based organizational schemes into OpenMeta tags, or translate between different schemes. Very cool.

For example, my current heirarchy is something like mainfolder/project/creator/files. I want to archive these files to another directory where I'd like to have them organized differently -- by creation date. I could set up a Hazel rule to look for files of a certain age, and move them to a different folder that might look like archivefolder/creationyear/creationmonth/creator/files -- and at the same time add both the project and creator as OpenMeta tags to make the archive more searchable. Tons of power there!

The subfolders can't be available as separate items at the rule creation stage, Hazel has no idea how many levels deep the path will be plus it will vary depending on where in the folder tree you are. One possibility would be to provide that as an attribute you can match on (and from there you can break it down into constituent parts). It's still being worked out.

Mr_Noodle wrote:The subfolders can't be available as separate items at the rule creation stage, Hazel has no idea how many levels deep the path will be plus it will vary depending on where in the folder tree you are. One possibility would be to provide that as an attribute you can match on (and from there you can break it down into constituent parts). It's still being worked out.

Yeah, that would be good way to handle it. If a file is at least 3 folders deep, then provide subfolder1, subfolder2, subfolder3. I have to imagine that would be really useful for anybody wanting to interpret an existing organization structure.

Although in the meantime, if there was even just a single subfolder that I could use in patterns for movement of files and OpenMeta tag creation, I would be thrilled. Lots I could do with that until the more complete scheme.

sherkaner wrote:Ew, I really don't want to clutter my filenames with the creator's name. Metadata belongs either in your folder heirarchy or something like OpenMeta (or both).

haha, no thats not what I mean. What I mean is using the filename as a temporary tag (useless when openmeta is successfully implemented). Here is what I was referring to:

File that you know was created by Frank is on the desktop: filename.pdf
You rename the file by appending his name: "Frank ** filename.pdf "
Hazel recognises the ** flag and sorts into the appropriate folder
Hazel renames the file "filename.pdf"

Its clumsy, I agree, but until openmeta works well, its what I've been using as temporary tags.Plus, if you type fast then its often faster than dragging and dropping.

sherkaner wrote:Yeah, that would be good way to handle it. If a file is at least 3 folders deep, then provide subfolder1, subfolder2, subfolder3. I have to imagine that would be really useful for anybody wanting to interpret an existing organization structure.

Actually, that's not how it would work. The whole problem is at rule creation time, there is no notion of how deep it is (that is dependent on the specific file which is something that only makes sense when you run the rule, not create it). So, there would just be one attribute (not sure what it will be called). You'd have to do your own pattern matching on that attribute to break it up into parts. Hope that clarifies things.

Mr_Noodle wrote:Actually, that's not how it would work. The whole problem is at rule creation time, there is no notion of how deep it is (that is dependent on the specific file which is something that only makes sense when you run the rule, not create it). So, there would just be one attribute (not sure what it will be called). You'd have to do your own pattern matching on that attribute to break it up into parts. Hope that clarifies things.

Man, I can't ever seem to get this right...

I get what you're saying, although that's why I was thinking that you'd only make those subfolder attributes available as the result of matching a file based on its subfolder depth. So that single attribute you mention would always be there, but if you'd already established that a file was, say, 2 folder deep through a match, then you could expose subfolder1 and subfolder2.

That said, that might not be something you're interested in implementing. Certainly having the total path to play with would be a start, although I hope you'll also offer the single immediate subfolder for each file (which should be safe in all circumstances -- for files that are at the top of the hierarchy, that attribute could either just be the name of the main folder, or empty). Those two would go a long way.

I know this topic hasn't been updated in over a decade (!), but was this feature ever added to Hazel?

Can you describe the actual situation you have now where you think this would be useful?