Please implement the --backup option

[peterhgruber]

Would be really great, should behave like this:

mv --backup=numbered <source_file> <dest_file>

See this discussion: https://serverfault.com/questions/267255/mv-rename-if-exists

[rrthomas]

Sounds like a good idea. I guess this flag would be used with --overwrite mode. (I don't think it makes sense for other modes.)

[peterhgruber]

Well the idea is somewhat the opposite, so to NOT overwrite and to spare the hassle of

1. having to find if a version of the file already exists at the target location
2. coming up with a renamed version (file_2.extension)
3. Potentially repeating 1-2

So the goal is to keep both, which obviously requires an (automatic) renaming.

[rrthomas]

In a mode other than overwrite or append, a destination coinciding with a source is considered an error. With --backup, the original file would be overwritten, but also backed up. The name --backup suggests that a copy of the file is made, rather than that the destination file is moved, so I don't think it's too confusing.

[ferdnyc]

@rrthomas

I got the impression the request here was somewhat different; less like the mv --backup option than many GUI programs' automatic name-retargeting.

If I'm using, say, Chrome, and I tell it to download foo.zip to my $HOME/Downloads directory, but there's already a $HOME/Downloads/foo.zip, then Chrome will simply, happily save the new download as $HOME/Downloads/foo (1).zip — without even bothering me for permission to do that, first.

It can get away with that because no existing files are being moved, renamed, overwritten, or touched in any way. The only thing that's altered from my original request is the destination filename (and even that's done in predictable ways that embody the Principle of Least Astonishment).

So, handled that way, it's an eminently safe operation which at worst wastes a bit of disk space, by keeping multiple files (possibly identical copies, possibly not) where the user expected to only have one.

Having an option in mmv to do that sort of thing automatically, instead of raising an error when a destination name collides with an existing file, could be helpful to some users. (And without requiring scary flags like --overwrite.)

[peterhgruber]

@ferdnyc Fully agree with your summary, and yes indeed the handling of browser downloads was an inspiration.

[rrthomas]

mv --backup makes more sense to me for mmv: because you can change an arbitrary number of files with one command, it's hard to understand what has happened if some of them have their new name changed, whereas if old files are moved out of the way, it's easier.

Another consideration is that I would like to actually use mv, cp etc. to implement the functionality of mmv, as these commands are more flexible and robust than mmv can hope to be without reimplementing them.

[ferdnyc]

it's hard to understand what has happened if some of them have their new name changed, whereas if old files are moved out of the way, it's easier.

I was actually going to bring that up, too. With mmv there is a danger of ending up in rename cycles with this, so it would definitely have to be optional.

A lot of times, I'll write "name-cleanup" scripts that use mmv to massage filenames into a preferred format, knowing that eventually they'll effectively be renaming files to the same name — that's how the script knows it's done. In those situations, mmv rewriting the destination names could lead to an effectively infinite loop.

(Not that it would literally be infinite, because mmv is smart enough not to pick up its own output files as input in the same run, but with this feature enabled its work would never be finished. Every run would bring more new renames to perform.)

Another consideration is that I would like to actually use mv, cp etc. to implement the functionality of mmv, as these commands are more flexible and robust than mmv can hope to be without reimplementing them.

While that's true... it's also true that the whole reason mmv exists is that they weren't robust enough, right? :grinning:

With mv --backup, in particular, the fact that it's only able to create backup names with a string appended after the file extension makes it more than a little bit useless, with how GUIs manage files these days.

Back 40 years ago when we were using dumb terminals, having your backup files be named foo.doc.1 and foo.doc.2 was fine. In the shell it doesn't make a difference. But in a graphical file browser, that's a problem.

[rrthomas]

I was actually going to bring that up, too. With mmv there is a danger of ending up in rename cycles with this, so it would definitely have to be optional.

Absolutely.

While that's true... it's also true that the whole reason mmv exists is that they weren't robust enough, right? 😀

My take is that mmv exists because the standard commands are not flexible enough, not that they aren't robust enough. Pretty much the opposite!

With mv --backup, in particular, the fact that it's only able to create backup names with a string appended after the file extension makes it more than a little bit useless, with how GUIs manage files these days.

That's unfortunate, but I'm not sure it's a big deal. There's nothing to stop graphical file managers being more intelligent, and with some schemes (e.g. adding .bak or ~) they are likely to work already. I can see that for example a dumb application might assume that a file ending .jpg.2 is a man page, but I don't think I would want to complicate the behaviour of mmv to deal with this. In any case, it would be possible with a small extension to the current syntax, something like making #b mean "the backup extension" in the replacement pattern.

[ferdnyc]

Not sure how much interaction you've had with the developers of certain open-source file managers I shall not mention by name, but I've had my share, and I think you'll find there's a lot stopping them. Nothing external, granted, but... still, plenty.

I'd sympathise with those developers. The number of users for whom this situation would matter is small, and the complexity of the feature is relatively high. I would say the main justification would be to improve support for files without suffixes or with incorrect suffixes (as a one-time user of RISC OS, I miss file type being encoded explicitly in the metadata!).