Odd behavior moving files on cache

[johnsanc]

I was watching a Spaceinvader One video about moving files around quickly between shares using a rootshare and was trying to figure out why my tests kept copying files instead of moving instantly. In his video he configured two shares that had a common disk and used the array as the primary storage.

 

After some testing, it turns out that if the file is on the cache drive it will always copy/delete instead of being moved instantly. I tested this in midnight commander as well moving a file that resided on the cache between /mnt/user/Downloads/Test to /mnt/user/Games/Test. 

 

I conducted the same test, this time with a file that resided on the array and it moved instantly across shares. I'm not sure if its a bug or by design, but this type of move doesn't honor the disk allocation rules either.

 

Either way, why does the cache behave in a way where cross-share movement must copy/delete but movement of a file on the array is instant?

 

That being said, I may adjust a few workflows because  in some cases its writing data to cache twice when it doesn't need to. E.g. first download to the Download share, then move to Games share where both shares use the cache drive as primary storage.

 

This isn't a big deal, more of a curiosity. Any insight is appreciated.

[itimpi]

You need to be very careful of any method that uses move at the Linux level that you do not fall foul of the behaviour described in the Caution in this section of the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page.    Using a Copy/Delete strategy should always give the expected results.

[johnsanc]

Yes that explains the behavior of not abiding by the disk allocation settings, but it doesn’t really explain why the movement of files on cache across shares is always copy and delete. Why would the attempted rename operation fail then fall back to copy/delete in that case?

 

It feels like this is just an area for some move logic improvements if files are already on the cache and just need to be moved across shares.

 

Also, for some reason I thought share settings are evaluated on any movement of files between shares to ensure both the allocation rules are followed and such that the movement is as fast as possible. For example, I thought a rename operation should occur only if both shares include the same disk number for which the file actually resides on the source share. If there is a mismatch then I would expect copy/delete. I thought this is why @SpaceInvaderOne setup his root share demo that way to ensure both shares included the same disk to allow for a rename, but apparently that’s not a requirement.

[cpxazn]

I'm having this same problem recently which I never had in the past. In the past, I was able to move file across shares through user directory instantly as long as source and target were both on cache. Now I'm seeing the copy and delete behavior that @johnsanc is mentioning. I've tried both on Windows 11 and Krusader and both have the same issue.

 

Edit: I just did a test without user directory, and tested directly from rootshare/cache/source-dir to rootshare/cache/target-dir, and it's still doing a copy/delete

 

Edit: Also wanted to mention that I was on btrfs (raid5) in the past, but now I'm on zfs (raidz and compression on), in case that makes a difference.

Edited December 3, 2023 by cpxazn