You are not logged in.
Had an interesting issue that I thought people might be able to weigh in on. I was writing a post-build script to rename the output of cargo for a rust project I was going to mess with - simple enough, just "mv target/debug/foo target/debug/bar". Except... for some reason this usage of mv fails once the target file already exists, saying "mv: 'target/debug/foo' and 'target/debug/bar' are the same file". As it happens the contents of the files are the same, but I'm not used to mv caring about that. Even passing -f to mv doesn't solve the issue, it still refuses to overwrite the target file saying the two are the same.
On a hunch I thought maybe it was a wonky interaction with btrfs, since my home dir is on a btrfs volume. I tried to do the same thing within an ext4 volume, and sure enough it works like I'd expect. mv just overwrites the destination file, easy peasy. So, that brings me here. Does it seem likely that this is most likely some weird interaction with mv and btrfs, like my troubleshooting suggests? If so, anything I can do about it (besides reporting it to the coreutils project in case it's a bug)? This is a rather bizarre issue to me so I'm hoping someone else might have some insight.
Offline
touch foo
ln foo bar
mv -f foo barOnline
That doesn't do the trick either - ln says "failed to create hard link 'bar': File exists". I could always do rm of course, but it's still super weird to me that I'm seeing errors instead of just overwriting the target file like usual.
Offline
That's not a trick but to illustrate the mv behavior when source and destination inode are the same.
It's either a hard link or deduplicated by btrfs.
Online