I noticed today that when you tick the “recurse” option in Copy File(s), the “Destination is a directory” flag automatically comes on. I guess this often makes sense, but it’s not necessarily the case. For example, if you’re copying *.html files to *.txt, recursively, you definitely don’t want to create directories called foo.txt. My actual example is a bit more awkward than that.
Steve
Maybe you can use a FileSet instead for this?
I guess. I have always avoided using filesets, despite the massive amount of copying I do, because you always end up with two steps: define fileset, act on fileset. And somehow “defining” something just doesn’t sit nicely as an FB action for me. But I really should give them a go 
Steve
FileSets can really be powerful… and this is due to the fact that you do define them and then other actions act on that “object” as opposed to a simple variable or string.
There are a few sets of actions that take advantage of this technology (internally we call it the ProjectObjectAPI): FileSets, PropertySets and XML Objects.
The XML ones are pretty cool, because it means you can open an XML document, manipulate it using various XML actions, and then finally persist it when you’re done. It removes all the overhead associated with opening and closing the document for each minor operation.
.t8
In my builds, I really can’t think of any places where I would use the same fileset more than once. I might purge the .obj files from a directory - but once they’re purged, I don’t need to deal with them anymore. Or I copy certain .exe’s into a bin directory - but again, once they’re copied, end of story.
It’s funny, because when I started using FB, I was convinced I was going to have filesets everywhere. But file iterators work so well (I really, really lerve them) that I just haven’t needed to - until this trick
Steve