Is it possible to make rm delete only the oldest copies of a file, if more than one is present?

[dagelf]

This could fix mv. If based on atime, or mtime. Not sure how these work with noatime or what kind of weird things programs do with them, maybe an extended attribute can be used? Of course you would have the weird situation of having to delete files multiple times to really delete them.

Maybe mergerfs could have an option where it adds a "moved" or "moving" attribute to files while moving?

I'm sure I've read motivations for/against this before but I can't find them now...

[trapexit]

I'm not exactly sure what you're asking for. Please describe the situation.

You have N files at the same relative path and instead of removing all of them on an unlink you want to remove just the oldest? Like the opposite of newest policy?

[dagelf]

Exactly. Similar... are there any unlink flags that alter its behavior?

[trapexit]

The unlink policy? Yes.

My asking about the use case / situation is not rhetorical. We are wasting time by not getting to the root concern.

[dagelf]

The root concern is making mv behave like the casual user expects, ie. moving a file instead of deleting it. I did find the warning (after deleting things I didn't want to delete) and I realize not everyone will have backups. I am sure you have thought it through and motivated why a workaround is not feasible somewhere, but I can't find the discussion or motivation.... and I can't see why this isn't a solution.

What are the possible unlink policies? I looked, and looked, and looked but couldn't find it in the docs. I thought I'd ask before I dig into the source.

https://github.com/search?q=repo%3Atrapexit%2Fmergerfs%20unlink%20policy&type=code

[trapexit]

The root concern is making mv behave like the casual user expects, ie. moving a file instead of deleting it.

I don't understand what you mean. mv will try to rename a file and should that fail with EXDEV will copy and delete. And there is nothing different about how it works with mergerfs as with any other filesystem.

What are the possible unlink policies? I looked, and looked, and looked but couldn't find it in the docs. I thought I'd ask before I dig into the source.

It's in the policy section.

https://github.com/trapexit/mergerfs#functions-categories-and-policies

https://github.com/trapexit/mergerfs#policy-descriptions

[trapexit]

Maybe mergerfs could have an option where it adds a "moved" or "moving" attribute to files while moving?

Not sure what you mean. There is no such thing as "moving" in a filesystem. There is open, read, write, close, rename, etc. a "mv" is a combination of numerous functions.

[dagelf]

Just trying to think out of the box... would detecting a stat, followed closely by a create of the exact same path, add significant overhead? What other cases are there when that happens? ... anyways this could trigger a flag to make unlink do nothing... or make it remove only the oldest copy. Or it could just do that anyways...

I just shudder to think how many irresponsible people out there have innocently run 'mv' on their un backed-up data...

[trapexit]

I don't understand what you're trying to accomplish.

I feel like we are struck in the xyproblem : https://xyproblem.info/

Can you explain to me the problem? The "user story"? Rather than asking about possible solutions? Why would you want to unlink a single file? How would that file have gotten there in the first place? Why would calling mv be a problem? Please just explain the situation.

[dagelf]

Trying to accomplish mv skipping the unlink step on the file it just moved, as a default... without other unintended repercussions.

[trapexit]

You are still explaining the solution rather than the problem. Why do you want mv to skip unlink?

Not unlinking a file when the file is requested to be unlinked will absolutely lead to problems. How could it not? A standard recursive removal will fail.