Problem after moving files between user shares


Rysz

Recommended Posts

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 by Rysz
Link to comment
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.

Link to comment
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? 😞 

Link to comment

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. 

Link to comment
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.

Link to comment
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 by Rysz
Link to comment

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 by Rysz
Link to comment
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.

Link to comment

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 by Rysz
Link to comment
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).

Link to comment
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 by Rysz
Link to comment
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.

 

 

Link to comment

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.