Rysz Posted October 26, 2020 Share Posted October 26, 2020 (edited) Hi all! So I've read that it's fine to move files between user-shares. (usershare<>usershare = OK, usershare<>diskshare = not ok) for the purpose of organizing files between user-shares. I thought I'd test this and moved a file from a user-share "download" (cache: yes) to another user-share "media" (cache: no) and later back to the original share. mv /mnt/user/download/test.jpg /mnt/user/media/ mv /mnt/user/media/test.jpg /mnt/user/download/ Now the file resided on the cache when it was in the "download" user-share due to enabled caching. I thought that moving it to a user-share with cache disabled would automatically put it onto a disk in the array as per the new user-share's disabled cache-rule. After moving the file with "mv" (command line), however, I checked under Shares and while the file is in the right user-share it says it is on the cache still. I now get a yellow warning sign next to the new share "media" with "Some or all files unprotected". So I tried moving back the file from the user-share "media" (cache: no) to "download" (cache: yes) as it was before. I still get the yellow warning sign next to the "media" user-share despite the cached file not being in there anymore. Is moving files between user-shares not OK and supposed to respect the respective destination user-share's disk settings? Why am I still getting a warning next to the share "media" when the cached file is not even there anymore? Thanks a lot for your help, much appreciated! Edited October 26, 2020 by Rysz Quote Link to comment
itimpi Posted October 26, 2020 Share Posted October 26, 2020 Just now, Rysz said: After moving the file with "mv" (command line), however, I checked under Shares and while the file is in the right user-share it says it is on the cache still. This is why it has not worked You have encountered a side-effect of the way the mv command operates under Linux. It first tries to do a simple rename (which is fast) and only if that fails does a copy/delete operation. In this case the rename has worked (the Linux level is not aware of user shares) so it has stayed on the drive. To avoid this happening you need to either do an explicit copy/delete or set the target share to Use Cache=Yes so that mover later moves the file to the array. You would not have encountered this issue if you had done it over the network rather than internally within the server. Quote Link to comment
Rysz Posted October 26, 2020 Author Share Posted October 26, 2020 1 minute ago, itimpi said: This is why it has not worked You have encountered a side-effect of the way the mv command operates under Linux. It first tries to do a simple rename (which is fast) and only if that fails does a copy/delete operation. In this case the rename has worked (the Linux level is not aware of user shares) so it has stayed on the drive. To avoid this happening you need to either do an explicit copy/delete or set the target share to Use Cache=Yes so that mover later moves the file to the array. You would not have encountered this issue if you had done it over the network rather than internally within the server. I have deleted the file and still get the yellow warning sign - any way to make the warning sign go away after this? Or did I just break something? 😞 Quote Link to comment
Rysz Posted October 26, 2020 Author Share Posted October 26, 2020 I fixed it by enabling cache on the "media" share and triggering the mover. Despite no files being there it seems to have refreshed the "protection" status of the share. I've disabled the cache again and now it's showing as green - thanks for the lesson learned. Going to just copy the files next time. Quote Link to comment
itimpi Posted October 26, 2020 Share Posted October 26, 2020 Just now, Rysz said: I have deleted the file and still get the yellow warning sign - any way to make the warning sign go away after this? Or did I just break something? 😞 It should auto correct. The fact it has not suggests you still have a file or folder in the wrong location. Did you remember so also delete the containing folder and not just the file? You should be able to find the culprit by going to the Shares tab in the GUI and click the 'folder' location against the share. That will show which files/folders are on which drive - and you can drill down if required to find the culprit. Quote Link to comment
Rysz Posted October 26, 2020 Author Share Posted October 26, 2020 (edited) 2 minutes ago, itimpi said: It should auto correct. The fact it has not suggests you still have a file or folder in the wrong location. Did you remember so also delete the containing folder and not just the file? You should be able to find the culprit by going to the Shares tab in the GUI and click the 'folder' location against the share. That will show which files/folders are on which drive - and you can drill down if required to find the culprit. The interesting part is I actually did this. After deleting the test file I checked both user-shares and confirmed the file was not there. The warning remained though, despite all other files and directories being on the parity-protected disks. It was only after switching the cache on & off and triggering a manual mover operation that it refreshed the status. Edited October 26, 2020 by Rysz Quote Link to comment
Rysz Posted October 26, 2020 Author Share Posted October 26, 2020 (edited) I've just been able to replicate this behaviour on my Windows machine as well. Putting a file on a cache-enabled user-share puts the file on the cache drive where it belongs. The warning sign shows up next to the user-share as there is an unprotected file (in the cache) - this is correct. When deleting the file from the user-share (using Windows Explorer, accessing the Samba share) the protection status is not refreshed. The warning sign next to the user-share remains until the mover is triggered manually and only then reverts back to green. Despite no unprotected file being there and the mover not moving anything (confirmed in logs) the protection status goes back to green. So a new file triggers a protection status refresh but a deletion does not, weird. Edited October 26, 2020 by Rysz Quote Link to comment
itimpi Posted October 26, 2020 Share Posted October 26, 2020 4 minutes ago, Rysz said: I've just been able to replicate this behaviour on my Windows machine as well. Putting a file on a cache-enabled user-share puts the file on the cache drive where it belongs. The warning sign shows up next to the user-share as there is an unprotected file (in the cache) - this is correct. When deleting the file from the user-share (using Windows Explorer, accessing the Samba share) the protection status is not refreshed. The warning sign next to the user-share remains until the mover is triggered manually and only then reverts back to green. Despite no unprotected file being there and the mover not moving anything (confirmed in logs) the protection status goes back to green. So a new file triggers a protection status refresh but a deletion does not, weird. I cannot replicate this. The only way I got the symptoms you describe is if I deleted the file but not the folder on the cache drive that corresponded to the share name. Running mover then removed this (empty) folder and the status went back to green. Quote Link to comment
Rysz Posted October 26, 2020 Author Share Posted October 26, 2020 (edited) It was the empty folder, thanks a lot for your help. Weird that an empty folder triggers "some or all files unprotected", one would think an empty user-share folder on the cache is no longer considered as "unprotected" when the last file was deleted from it. 🤨 Edited October 26, 2020 by Rysz Quote Link to comment
itimpi Posted October 26, 2020 Share Posted October 26, 2020 1 minute ago, Rysz said: It was the empty folder, thanks a lot for your help. Weird that an empty folder triggers "some or all files unprotected", one would think an empty user-share folder on the cache is no longer considered as "unprotected" when the last file was deleted from it. 🤨 I think the point is that if you were doing things over the network then this situation would never arise so is has not been catered for (perhaps for efficiency reasons). Quote Link to comment
Rysz Posted October 26, 2020 Author Share Posted October 26, 2020 (edited) 9 minutes ago, itimpi said: I think the point is that if you were doing things over the network then this situation would never arise so is has not been catered for (perhaps for efficiency reasons). I did do this over the network though just now and the very same thing occurs. If you're interested you can reproduce it like this over the network: 1. Invoke the mover to make sure that all your files are protected - the green light will be next to your cache-enabled user-share. 2. Drag a single file onto the cache-enabled user-share (via Samba, etc..) - the light will turn yellow as the file will be on the cache drive. 3. Delete the file and check the status of the light - it will remain yellow due to the empty user-share-named directory on the cache drive. 4. Invoke the mover (removes the empty user-share-named directory from the cache drive) and only then you get a green light. What I am saying is that this behaviour is not limited to rare command-line operations. Basically any time you delete the last cached file on a cache-enabled user-share the empty folder on the cache drive will be considered as "unprotected files", as long as you do not invoke the mover and that directory gets removed. Edited October 26, 2020 by Rysz Quote Link to comment
itimpi Posted October 26, 2020 Share Posted October 26, 2020 I guess that might make it happen as that would create the folder. The yellow status is triggered by there being a folder corresponding to the share name. The system does not look inside the folder to check its contents. Quote Link to comment
Rysz Posted October 26, 2020 Author Share Posted October 26, 2020 1 minute ago, itimpi said: I guess that might make it happen as that would create the folder. The yellow status is triggered by there being a folder corresponding to the share name. The system does not look inside the folder to check its contents. Fair enough - thanks a lot for figuring this out with me. Definitely a valuable lesson learned regarding move-operations between user-shares. 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.