Dear list,
If a file is copied from tmpfs onto a bind mount, the contents update
as expected. However if a file is _moved_ from tmpfs onto a bind
mount, the old content persists.
For example, my PC has a tmpfs on /run:
# findmnt /run
TARGET SOURCE FSTYPE OPTIONS
/run tmpfs tmpfs rw,nosuid,nodev,noexec,relatime,size=5737612k,mode=755,inode64
Set up a bind mounted file...
# touch /opt/file
# echo one > /home/file
# mount -o bind /home/file /opt/file
# cat /opt/file
one
Coping a file onto the bind mount via the tmpfs on /run yields...
# echo two > /run/file
# cp /run/file /home/file
# cat /opt/file
two
So far, so good. Now do the same, but with 'mv' instead of 'cp'...
# echo three > /run/file
# mv /run/file /home/file
# cat /opt/file
two
At this point, the contents of /opt/file are stuck forever with "two"...
# echo three > /run/file
# cp /run/file /home/file
# cat /opt/file
two
# echo three > /home/file
# cat /opt/file
two
What is going on here? Is this a bug or a feature?
Thanks,
Richard
On Thu, Apr 13, 2023 at 05:23:13PM -0700, Richard Cochran wrote:
> So far, so good. Now do the same, but with 'mv' instead of 'cp'...
>
> # echo three > /run/file
> # mv /run/file /home/file
> # cat /opt/file
> two
>
> At this point, the contents of /opt/file are stuck forever with "two"...
>
> # echo three > /run/file
> # cp /run/file /home/file
> # cat /opt/file
> two
> # echo three > /home/file
> # cat /opt/file
> two
>
> What is going on here? Is this a bug or a feature?
strace and compare the traces... cp(1) opens the existing
target, truncates and writes to it; mv(1) tries rename(),
falling back to unlink()+creat()+write() in case rename()
failed with -EXDEV.
The same behaviour can be seen without any mount(2) use:
; echo x > a
; ln a b
; echo y > c
; cat a
x
; cat b
x
; cat c
y
; cp c a
; cat b
y
; echo x > a
; cat a
x
; cat b
x
; mv c a
; cat a
y
; cat b
x
;
Exact same underlying cause - writing down what happens
step-by-step might be enlightening...