Yes, that is the correct way to use it - it creates a new file with a new unique name, and then you can write to that file by some other means knowing it will be unique.
Yes, the “copy n” should be before the extension, I will look at getting that fixed.
This is done for 10.0.2.
Is there a way to get the Write to a File action to create unique files too? Would be super handy if subsequent files with the same name were numbered.
That's nifty! So the first action looks at the directory to see how it should name a file and the second actually creates it. I think I get it now. Thanks!
EDIT: Actually no, that's not what I was talking about. This copies an existing file and adds "copy 1" to the filename.
I'm talking about the Write to a File action which can actually generate a new file from a clipboard. I mistakenly thought there might be a way, when creating a new file in this way, that it could look at the destination directory, see if there's already a file with the same name and, if so, add a number to the new file's name so it doesn't overwrite the existing one.
I empathize. I simply wanted to point out the equivalence in case others didn't know about it. And to make sure I understood your request.
FOOTNOTE: I didn't want to add this footnote, but the web server didn't let me post the exact same text in a separate thread. That's so sad, because I thought it was hilarious that I could write two identical posts in two separate threads and both of them be meaningful and correct.
This can be done, but you have to script it – or use a loop in a Keyboard Maestro macro to try to rename your unique file to the desired name and increment if there is a failure due to a collision.
-Chris
It could, but you only need to do that if you're unhappy with how KM/the OS handles duplicate names, i.e. test.html, test copy 1.html, test copy 2.html, etc -- those come "free" with the "Create Unique File" action.
You'll need to either edit "Create Unique"'s path or make a folder on your Desktop call "fileTestFolder" for this example:
Unique File Test.kmmacros (3.1 KB)
I'd start with why these duplicates are being generated, whether you need to keep the previous "version", the most appropriate naming convention, and so on -- for example, it might be all-round better to always generate the file names with appended time stamps for both uniqueness and the instantly available metadata.
Thanks. This is great. And the reason "why" I wanted to do this is that sometimes I want to overwrite a file and sometimes I want to keep versions (depending what option I choose in a Prompt). I had already been using the timestamp idea but this seems neater.
It might be worth mentioning that your example Macro only needs these three Actions to make unique versions of a Write System Clipboard to File Action. I do find this "Create Unique" option quite confusing, but you have clarified it for me with your example.
I did the extras so it would loop and put different data into each "duplicate" file name so it was obvious that each was, indeed, different, and to check that each loop would skip over any previously-appended file names to the next available number.
For my sake as much as anyone else's -- appending "Copy n" to the file name implies (to me, at least) that it's a copy of the original, and I wanted to prove to myself that it wasn't!
Yes, that's true. So, maybe this isn't such a great way to indicate version numbers... That's why I was wondering if your other method (-001 -002 etc) could be adapted to the Write System Clipboard to File Action
"Write to file" doesn't (AFAIK) error out if there's already a file. So we're back to test-then-write. I'd prefer to have "v01" etc to show these are deliberate versions, because the folks at work do a lot of image sequence exports and similar which get the "-001" treatment. So:
Thank you. That works really well. I was able make it into a Subroutine to use in my Macros.
And editing the three occurrences of v00 in the Actions to another format such as -000 or Copy-00 allows any number format to be used (as in your original Macro on the other thread).
Next move would be to pass the formatting string in as a parameter 
I think you could do that by double-%ing the rest of the line, Filtering with "Process tokens", then using the result in the test/write actions, but I didn't get that far. Maybe one for after-dark...
Unless you're already there?
Yes, I've got that to work by doing exactly what you suggested. In my Subroutine the Filter Action looks like this (which is a lot of %s !)
And the Parameters in the Subroutine are:
LOCAL__Folder is the path to the containing folder
LOCAL__File is the filename to be used for the Save Clipboard to File
LOCAL__Extension is the extension such as png or txt or kmmacros
LOCAL__NumberFormat is the number format such as -000 or (000) or v000 or version000 etc, written as it will appear after the filename, with the number of digits being shown by the number of zeros.
I also had to add in a Switch Case depending on the file extension for the format the file is saved in.
Uploaded here for info and to be adapted for other file types etc.
Write Clipboard with Rename on Conflict @Nige_S (Subroutine).kmmacros (7.4 KB)
Nice!
My go at this, unsurprisingly, has the same filter. But I went with passing in a complete path, including file name (IMO, easier to do the split in the sub rather than in every caller). I also changed the logic around -- I don't use the "Until" action enough, and using it here means we don't have to prime the variable before the loop. And I've separated the checks from the writes -- that way, there's only one "Switch/Case" block to update for new file types.
SUB - Write Clipboad and Rewrite on Conflict.kmmacros (9.0 KB)
One obvious improvement would be to return a value to the caller to indicate success (perhaps the final file path used?) or any error (wrong format on clipboard for given extension, broke the version limit).
Yes, this is so much neater - I didn't like having to have two sets of Switch Case and I was sure you'd come up with a way around that 
I've updated my version of your macro to work this new way.
I'm not sure you need to limit to 100 versions - just having three zeros in the format, such as v000 will give way more versions than would ever be needed.
Yeah, that was copied over from the previous version.
And that was in there because, in AppleScript, I'd pad numbers by casting to text, prepending some 0s, then taking the last n characters:
set theNum to characters -3 thru -1 of ("000" & 2) as text
...which has the obvious problem of 99 being returned as 99 but 100 as 00, so you need a stop condition to prevent an endless loop once you have 100 versions -- 101 is 01, which you already have, etc.
%CalculateFormat% doesn't have that problem -- %CalculateFormat%101%00% returns 101 -- so the boundary check is redundant.