Move

Adding a file to a collection is a different node — see Assign. A collection is a grouping, not a place, so nothing is moved.

Three deliberate refusals, because a file mover that gets these wrong destroys work that cannot be recovered.

It never overwrites. If something is already at the destination with the same name, the incoming file lands beside it as clip_1.mp4, or the item is skipped, or the step fails — whichever you chose. There is no "overwrite" setting, because a name collision in a trash folder is very often a completely different file that happens to share a name.

It only ever removes an original after checking the copy. Within one disk the file is renamed, so there is only ever one copy of it and nothing is deleted — the flag port reads MOVED. Across disks the bytes have to be written a second time, and there the node keeps the original by default and says so: the flag reads COPIED. Removing it is something you switch on, and even then it happens only after the destination has been checked to hold the same content.

It does not silently spend an hour copying. Moving a file within one disk is instant. Moving it to a different disk is a full copy of every byte, and for a 40 GB video that is a very different operation. The node works out which it would be before it starts, and by default declines the second one rather than surprising you with it. You can tell it to go ahead — it will, and it will say so in the log, naming both disks and the size.

The usual shape is three nodes: something decides, the filter routes, and this node acts.

Start with Dry run switched on. You will see exactly which files would move and where, without anything being touched.

The same three nodes build a quarantine workflow — only the tag and the destination change.

Deduplication finds duplicates and, for near-duplicates, waits for a person to confirm them. Those nodes no longer move anything themselves: they report their findings, and you wire that into this node. That way the destination, the conflict handling and whether the original survives are all visible in the pipeline instead of buried in a worker’s configuration.

Wire the confirmed_dup port of the dedup apply node into this node’s media port.

After a successful move the asset’s binary record points at the new location, and the asset’s file name is kept in step with it. A processing record notes what happened, so the run history shows the move alongside everything else that touched the asset.

If the file moves to a bucket, the record holds an s3:// reference and the file name is deliberately left alone — it is a local path, and pointing it at a bucket would break everything that reads it.

Turn on Debug Mode and every node keeps what it produced, on the card itself. Below is a real run of this node, sending a photograph to a trash folder.

The strip on the card lists what each output port carried — moved, path, flag. path is where the file is now, and it is the port to read when you need to know that; flag reads MOVED here because the destination was on the same disk, so relocating the file was a rename.