Moving Files using SFTP causing user share to become cache enabled

[Dark_Gypsy]

So I recently migrated my existing data to a brand new server running 6.4.0-rc7a. My old server did not have a cache pool. I created a cache pool in the new server. I enabled some shares to be cache enabled including Downloads, system, appdata. I had a bunch of files I wanted to move using SFTP (winscp). I moved them from the downloads folder which is set to use cache "yes", to another folder called backup that was not set to be cache enabled. As soon as I moved them, I noticed the allocated space on my cache drive did not change. So I browsed through the web gui to see what was in my cache drive, and the backup share now appears in there with the files I moved. As a test, I created a new share using the web interface and ensured it was not set to use the cache drive. Again, i moved files using winscp, and again the share then showed up in my cache drive. To further test, I instead moved the files the same way using network shares through win 10, and, this did not cause the new share to show up on my cache drive. I don't want to move them using network folders as it takes forever compared to SFTP. Am I missing a setting somewhere or is this some sort of bug?

[itimpi]

It is not clear from your description exactly what commands you used to move the files.    The SFTP process is working at the Linux Level (rather than the network share level) and this allows you to bypass the normal User Shares handling.    It is likely therefore that this is what is happening, but without knowing the exact commands you were using it is difficult to be sure.

[Dark_Gypsy]

Ok well, this is the most efficient way that I know of to manually move files. If there is another method to move files that will not cause this problem, please let me know. Using network shares is not a good option as it takes significantly longer to transfer files this way.

 

Winscp has a GUI so all i do is right click, hit "move to" and put in the destination path. Here is what the winscp log shows after moving a simple text document (test2.txt) from the Downloads share to the Backup share.

 

2017-08-28 17:11:50.158 Moving file "test2.txt" to "/mnt/user/Backup/test2.txt".
> 2017-08-28 17:11:50.159 Type: SSH_FXP_RENAME, Size: 68, Number: 5394
> 2017-08-28 17:11:50.159 12,00,00,15,12,00,00,00,1D,2F,6D,6E,74,2F,75,73,65,72,2F,44,6F,77,6E,6C,6F,
> 2017-08-28 17:11:50.159 61,64,73,2F,74,65,73,74,32,2E,74,78,74,00,00,00,1A,2F,6D,6E,74,2F,75,73,65,
> 2017-08-28 17:11:50.159 72,2F,42,61,63,6B,75,70,2F,74,65,73,74,32,2E,74,78,74,
. 2017-08-28 17:11:50.159 Sent 72 bytes
. 2017-08-28 17:11:50.159 There are 0 bytes remaining in the send buffer
. 2017-08-28 17:11:50.159 Looking for network events
. 2017-08-28 17:11:50.159 Timeout waiting for network events
. 2017-08-28 17:11:50.159 Waiting for another 4 bytes
. 2017-08-28 17:11:50.159 Looking for incoming data
. 2017-08-28 17:11:50.159 Looking for network events
. 2017-08-28 17:11:50.160 Detected network event
. 2017-08-28 17:11:50.160 Enumerating network events for socket 2616
. 2017-08-28 17:11:50.160 Enumerated 1 network events making 1 cumulative events for socket 2616
. 2017-08-28 17:11:50.160 Handling network read event on socket 2616 with error 0
. 2017-08-28 17:11:50.160 Received 28 bytes (0)
. 2017-08-28 17:11:50.160 Read 4 bytes (24 pending)
. 2017-08-28 17:11:50.160 Read 24 bytes (0 pending)
< 2017-08-28 17:11:50.160 Type: SSH_FXP_STATUS, Size: 24, Number: 5394
< 2017-08-28 17:11:50.160 65,00,00,15,12,00,00,00,00,00,00,00,07,53,75,63,63,65,73,73,00,00,00,00,
< 2017-08-28 17:11:50.160 Status code: 0
. 2017-08-28 17:11:50.162 Listing directory "/mnt/user/Downloads".

 

After moving this single file, My Backup Share is now showing on the cache drive with this file in it.

 

 

 

 

 

[itimpi]

That log shows that it first trying a simple rename and since that works at the Linux level it stops there.   However the rename has left it on the same physical device (the cache drive) and thus the symptoms you see.    You need the move to be executed as a copy/delete process for the User Share settings to have an affect.

[Dark_Gypsy]

2 minutes ago, itimpi said:

That log shows that it first trying a simple rename and since that works at the Linux level it stops there.   However the rename has left it on the same physical device (the cache drive) and thus the symptoms you see.    You need the move to be executed as a copy/delete process for the User Share settings to have an affect.

This log is from when I right clicked on the file, and hit "move to" and selected the path to my backup share. It then moved the file. 

So I hit move to, selected the path to backup share, it moved it just fine, i verified it was in the backup share, and that caused the backup share to be on the cache drive even though it wasn't cache enabled..... why?? How is everyone else moving files without this problem. Is it because of Winscp? Should I try another client? Is there a better way to move files that doesn't use network shares?? I don't understand why moving a file would cause a user share to suddenly and mysteriously become cache enabled....

[Dark_Gypsy]

As another test. I used Dolphin running in a Docker container to cut/paste a file from downloads share to Movie share, and again, that also causes the Movie Share to show the content on the cache drive.

Edited August 29, 2017 by Dark_Gypsy

[Dark_Gypsy]

I solved this.

 

If you are in the path /mnt/user/Downloads, and move a file from there to /mnt/user/Movies, it will cause the Movies share to become cache enabled, and show that file on the cache drive.The only way to fix that, is to go to the Movies share settings, set it to "Yes" for using the cache drive, then manually run the mover. Once the file is moved off of the cache drive, you then have to go back into the Movies share settings, and set it to "No" for using the cache drive.

 

 If you are in the path /mnt/user0/Downloads, and move a file from there to /mnt/user0/Movies, the file moves normally, and no share becomes cache enabled.

 

Since I was not very familiar with the Cache drives having just added them, I wasn't aware of the difference between user and user0. Now I know.

If anyone else stumbles across this, the difference between those two paths is this:

 

/mnt/user/ <-- this shows ALL of the shares including the array and cache drives

/mnt/user0/ <--this shows ONLY shares on the array and NOT any shares on the cache drive.

 

[trurl]

The cache settings for the share are not changed, so I wouldn't call it "cache enabled". The only thing that happened is some files from the share wound up on the cache drive. See here for a more complete explanation of cache settings: