Unexpected behaviour CLI file move/copy (CLI vs GUI)

[Mat W]

I prefer CLI vs GUI for basic file management, call me old school.  I'm seeing some unexpected behaviour that I'm not 100% is an actual bug.  Figured I should post in here before opening one.  I'll do my best to explain this clearly but forgive me if I don't...

 

Let me preface this by saying that if I use a GUI file manager (dynamix plugin, MacOS Finder, MacOS Commander One) everything works as expected, the file goes where it should.  This only occurs when done from the unRAID CLI.

 

NOTES:

• The following is all done using /mnt/user/<share> and then verifying where the file goes by looking in /mnt/<cache drive>
• The following is done on a recently created file (uploaded or manually created) BEFORE Mover runs
• The following does NOT occur if Mover has already moved the file on share-A from the cache drive to the associated data drive
• If the 'cp' command is used the file goes where expected given the share settings

 

Config details:

• share-A is set to "Yes : cache-1"
• share-B is set to "Prefer : cache-2"
• Various tests showed that the "Included disk(s):" setting did not affect the behaviour

 

Description:

When moving (mv command) a recently created file from share-A to share-B, the file incorrectly gets put on cache-1 in a directory for share-B.  Thus Mover, correctly, does not move the file because it is not on the data drive set for share-B.

 

Let me know what additional info is needed.  I have attached a copy of the diagnostics just in case.

unplucky-diagnostics-20220801-1030.zip

[trurl]

Linux "repaths" the file onto the same disk, known behavior and nothing to be done about it. Copy from source to destination then delete from source.

[Mat W]

2 minutes ago, trurl said:

Linux "repaths" the file onto the same disk, known behavior and nothing to be done about it. Copy from source to destination then delete from source.

 

Kind of suspected it to be a Linux thing and how it deals with files, just couldn't find a definitive with my google-foo.  Appreciate the confirmation!

[trurl]

Other surprises await if you try to mix disks and user shares while moving or copying due to linux not understanding that disks and user shares are different views of the same files. You can lose data when linux tries to write over the file it is trying to read. For move/copy, only work with disks, or only work with user shares.

 

And as mentioned, mv is used to both rename and to move files. So

3 minutes ago, trurl said:

Linux "repaths" the file onto the same disk, known behavior and nothing to be done about it. Copy from source to destination then delete from source.

 

[Mat W]

Just now, trurl said:

Other surprises await if you try to mix disks and user shares while moving or copying due to linux not understanding that disks and user shares are different views of the same files. You can lose data when linux tries to write over the file it is trying to read. For move/copy, only work with disks, or only work with user shares.

 

And as mentioned, mv is used to both rename and to move files. So

 

You don't tempt me with a good time. lol

[trurl]

Dynamix File Manager knows all this and won't let you make these mistakes. Other tools, cli, Krusader, mc (Midnight Commander), etc. you have to be careful with.

[itimpi]

BTW:  This behaviour is documented here in the online documentation accessible via the 'Manual' link at the bottom of the GUI.