March 22, 20197 yr Community Expert 1 hour ago, Squid said: Imagine this /mnt/user/share1/file1.txt (this is a cache-only share) From the command prompt, move the file to another share that is set to not use the cache. mv /mnt/user/share1/file.txt /mnt/user/share2/file.txt The file will remain on the cache drive in the share2 folder, in apparent violation of the use cache setting. IMO, not a big deal as you're basically bypassing the system, but this can happen on occasion depending upon how you've set up docker containers (in particular if for simplicity sake you simply map /mnt to /mnt and nothing else). One way to work around this is to refer to user0 for the share that doesn't use cache. mv /mnt/user/share1/file.txt /mnt/user0/share2/file.txt Unfortunately, users aren't aware of the problem or the workaround. To the user, it is surprising behavior, but not as potentially disastrous as the surprise they get with the "User Share Copy Bug". 1 hour ago, limetech said: Interesting problem which doesn't come up when moving stuff around via SMB. What is the thing that is executing the 'mv' command in OP's issue? Lots of ways users and their setups can work with files directly on the server instead of over the network these days and without ever going to the command line.
March 22, 20197 yr 59 minutes ago, trurl said: Lots of ways users and their setups can work with files directly on the server instead of over the network these days and without ever going to the command line. I'll have to think about this. What happens with 'mv' is that it thinks source and destination are in the same file system (/mnt/user) and so it ends up doing a 'rename()' which is the operation 'shfs' sees (and also performs). I could certainly add code that analyses share config and do a 'copy' instead, but what concerns me is that rename() is special in the file system: the vfs layer ensures rename() is atomic, and if we actually did a copy, it would break this, which could lead to other very strange issues, and even data loss, if some application was relying on that.
May 28, 20197 yr I agree, you should alias the mv command to a script that checks if the source/destination is cache/no-cache. Are you guys gonna handle this or should 'the community' come up with this lil' script? :-D
June 17, 20215 yr I just had to solve this problem and wanted to add here that this is NOT FIXED yet, and that I don't think it really needs fixing. It should just be a little bit better communicated, that one needs to use the way through /mnt/user0/ to copy/move data from cache to shares which have using cache set to NO. Maybe a popup note when you set a share to "use cache: NO"? Like "Don't forget to move data from the cache to this share through /mnt/user0/ to prevent errors or even data loss", or something like that?
June 18, 20215 yr 3 hours ago, McFex said: I just had to solve this problem and wanted to add here that this is NOT FIXED yet, and that I don't think it really needs fixing. It should just be a little bit better communicated, that one needs to use the way through /mnt/user0/ to copy/move data from cache to shares which have using cache set to NO. Maybe a popup note when you set a share to "use cache: NO"? Like "Don't forget to move data from the cache to this share through /mnt/user0/ to prevent errors or even data loss", or something like that? For some, me for one, we use cache : no with files staying on the cache on purpose. Cache : No means new files added to the share go directly to the array, and files placed on the cache manually for high speed access in the share will stay on the cache without being disturbed by the mover. So, in my opinion, it's not a problem at all, but a needed feature.
Archived
This topic is now archived and is closed to further replies.