Creating a Uniquely Named Folder

I finally got my thinking cap on. Not sure how robust or efficient this is, so please feel free to chip in if you think you can improve it. Try it out and watch for incremental Test folders being created on the desktop.

Create Unique Folder.kmmacros (26 KB)

Macro screenshot

I'd worry about the "If Local__Path contains..." test -- what if a folder higher up the tree has the new folder name as a substring? Perhaps change that to "Local__Path ends with /%Variable%Local__FolderName%" for safety?

Anyways, as a fan of the brain-dead loop, here's another take on it (which I'm sure could be improved):

Create Unique Folder 2.kmmacros (5.0 KB)


1 Like

Hey Guys,

I think I'd use a Try or Catch action for this, but I'm not going to take the time to test the merits right now.


1 Like

That was my first thought too (Great minds? Fools? You decide!). But I spent a few minutes trying and gave up.

Consider the following -- run it twice:

Create Unique Folder 3.kmmacros (4.3 KB)

It would appear that "Create New Folder" is successful even when the folder already exists.

Facepalm moment! :man_facepalming:t2:

I really like the readability of your While approach. Great!

Yeah the potential for errant overwrites is the basis for my interest in this.

Sorry -- I should rephrase that.

It appears that the "Create New Folder" action returns "OK" even when the action does nothing because the folder already exists, ie it fails gracefully but silently so there's no error to Catch.


Hey @peternlewis,

Is this kosher?

See post #14...

I would tend to expect the New Folder action to return a non-zero status error (in essence).

Failure aborts macro and Notify on failure do not return the expected results either.


This works:


So I'm doubly surprised that the KM action fails.


I very much doubt it does -- I'd bet that the API the KM action uses is returning a misleading value.

Yes, I trust @peternlewis more than I trust Apple ; -)

Yes. The Create Folder succeeds without error if the folder already exists.

This is how it is coded. Perhaps it should be coded differently, but this is by design.


Please think that over if you would.

It's counterintuitive and unlike other scripting languages like Bash and AppleScript.

It is always problematic to change an existing behaviour. It can lead to macros suddenly stopping working and producing errors where they never did previously.

While that's true – this is an edge case that's fairly unlikely to affect very many people – and the change in behavior is eminently logical.

1 Like

I'm not sure about that, an entirely reasonable sequence would be:

  • Create Folder ~/StorageLocation
  • Write File ~/StorageLocation/%Date%.txt

with the expectation that the folder is simply recreated if it doesn't exist.

1 Like

@ccstone @peternlewis - well I’m apparently one of those people who lives on the edge!

Before I discovered

I used to write fairly clunky macro sections to check for the folder’s existence. And I’m sure I only realised I could avoid doing the folder-exists check after reading about it somewhere here in the KM forum. So my vote is keep the action’s behaviour as-is because it is entirely reasonable.

BTW, this discussion went off-topic at around post #11; shouldn’t it be split off?

Shall we mark this one as the solution?

If it did error, all you would have to do is turn off the error and notification, so it would be better in general if it did. But as I say, I don't really want to change it. Potentially I could change it and grandfather in a turn off of notification and error. (EDIT: That would not work since there are other valid reasons for it to error that should not be automatically turned off).

1 Like

This is probably not do-able -- but would it be possible to differentiate between a naked "Create Folder" and one in a "Try/Catch" block, keeping current behaviour for the first and throwing an error in the second?

That could give us the best of both worlds...