From aa56e120407980ed6595924c015e3d25b1f0e144 Mon Sep 17 00:00:00 2001
From: Antonio SJ Musumeci <trapexit@spawn.link>
Date: Sun, 6 Jan 2019 13:17:21 -0500
Subject: [PATCH] mention mv quirk in known issues

---
 README.md      | 18 ++++++++++++++++++
 man/mergerfs.1 | 26 ++++++++++++++++++++++++++
 2 files changed, 44 insertions(+)

diff --git a/README.md b/README.md
index 2b6f2841..3f88f743 100644
--- a/README.md
+++ b/README.md
@@ -533,6 +533,24 @@ The reason this is the default is because any other policy would be far more exp
 
 If you always want the directory information from the one with the most recent mtime then use the `newest` policy for `getattr`.
 
+#### `mv /mnt/pool/foo /mnt/disk1/foo` removes `foo`
+
+This is not a bug.
+
+Run in verbose mode to better undertand what's happening: `mv -v /mnt/pool/foo /mnt/disk1/foo`
+
+```
+$ mv -v /mnt/pool/foo /mnt/disk1/foo
+copied '/mnt/pool/foo' -> '/mnt/disk1/foo'
+removed '/mnt/pool/foo'
+$ ls /mnt/pool/foo
+ls: cannot access '/mnt/pool/foo': No such file or directory
+```
+
+`mv`, when working across devices, is copying the source to target and then removing the source. Since the source **is** the target in this case, depending on the unlink policy, it will remove the just copied file and other files across the branches.
+
+If you want to move files to one drive just copy them there and use mergerfs.dedup to clean up the old paths or manually remove them from the branches directly.
+
 #### cached memory appears greater than it should be
 
 Use the `direct_io` option as described above. Due to what mergerfs is doing there ends up being two caches of a file under normal usage. One from the underlying filesystem and one from mergerfs. Enabling `direct_io` removes the mergerfs cache. This saves on memory but means the kernel needs to communicate with mergerfs more often and can therefore result in slower speeds.
diff --git a/man/mergerfs.1 b/man/mergerfs.1
index 8bb98099..47ddf979 100644
--- a/man/mergerfs.1
+++ b/man/mergerfs.1
@@ -1140,6 +1140,32 @@ possibly spin up sleeping drives.
 .PP
 If you always want the directory information from the one with the most
 recent mtime then use the \f[C]newest\f[] policy for \f[C]getattr\f[].
+.SS \f[C]mv\ /mnt/pool/foo\ /mnt/disk1/foo\f[] removes \f[C]foo\f[]
+.PP
+This is not a bug.
+.PP
+Run in verbose mode to better undertand what\[aq]s happening:
+\f[C]mv\ \-v\ /mnt/pool/foo\ /mnt/disk1/foo\f[]
+.IP
+.nf
+\f[C]
+$\ mv\ \-v\ /mnt/pool/foo\ /mnt/disk1/foo
+copied\ \[aq]/mnt/pool/foo\[aq]\ \->\ \[aq]/mnt/disk1/foo\[aq]
+removed\ \[aq]/mnt/pool/foo\[aq]
+$\ ls\ /mnt/pool/foo
+ls:\ cannot\ access\ \[aq]/mnt/pool/foo\[aq]:\ No\ such\ file\ or\ directory
+\f[]
+.fi
+.PP
+\f[C]mv\f[], when working across devices, is copying the source to
+target and then removing the source.
+Since the source \f[B]is\f[] the target in this case then when the
+remove happens it can, depending on the unlink policy, remove the just
+copied file and other files across the branches.
+.PP
+If you want to move files to one drive just copy them there and use
+mergerfs.dedup to clean up the old paths or manually remove them from
+the branches directly.
 .SS cached memory appears greater than it should be
 .PP
 Use the \f[C]direct_io\f[] option as described above.