trurl Posted March 22, 2019 Share Posted March 22, 2019 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. Quote Link to comment
limetech Posted March 22, 2019 Share Posted March 22, 2019 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. 1 Quote Link to comment
Osiris Posted May 28, 2019 Share Posted May 28, 2019 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 Quote Link to comment
McFex Posted June 17, 2021 Share Posted June 17, 2021 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? Quote Link to comment
JonathanM Posted June 18, 2021 Share Posted June 18, 2021 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. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.