Jump to content
  • 0

Possible symlink resolution issue on Drivepool shares


Alyred

Question

Hello!  I've been using Drivepool for around a month now, and have found it extremely useful and well constructed. Last night I found a quirk with symlinks on NTFS that I think I should pass along, though.

 

I am running Stablebit Drivepool on a server with folders in the drive pool shared out to allow for duplications of a couple of redirected My Documents folders. Most of this works great; however, I've set up a couple of Symlinks ine one of the documents folders to redirect back to the local drive because of a couple of terribly-coded programs try to look there automatically to store significant amounts of data that are not kind on network bandwidth. The programs are unable to be configured to point elsewhere.

 

Doing this requires a switch in how symlinks can be resolved from remote to local (this is disabled by default in Windows 10). I've configured this to allow Remote-to-Local symlinks to be honored.  On the previous non-drivepool configuration (On another server), this worked without issue: The directory symlink in the documents folder, when clicked on, would open the folder on the local computer. I tested by switching the user account back to the old server last night and it worked flawlessly. Switching back to the server with Drivepool, the same constructed symlinks didn't work at all, just an error as to how the file doesn't exist or is unavailable.

 

Digging in a little last night, I saw symlinks were supported in Drivepool and even where the special folder is for the data to be stored. I checked and saw data there. So as a test, I tried to resolve the symlinks from the server itself and got the same error... so I artifically constructed the directory structure on the server that the user had on the user's local workstation... and the symlinks worked. Then I tried on the user's computer... and the symlinks worked as well, but showed the directory contents of the temporary testing server folders that I had made instead of the local workstation.

 

So it appears that Drivepool symlinks are resolving locally to the server, rather than "on the fly" when they are accessed?

 

Steps to Reproduce:

On the server:

1. Create pool on server.

2. Create a folder in the pool and set it to duplicate between two members of the pool.

3. Share folder.

4. Create C:\Target directory.

5. Create empty server.txt file in C:\Target (as a placeholder)

 

On Workstation:

6. Map network drive to share.

7. Create folder on C drive for a symlink target. (C:\Target)

8. Open command prompt as administrator.

9. Adjust setting to allow Remote-to-Local Symlinks:

     a. fsutil behavior query SymlinkEvaluation to check current status

     b. fsutil behavior set SymlinkEvaluation R2L:1

10. While in the mapped drive, set up the symlink: mklink /d Target C:\Target

 

In that share in Windows explorer, the expected behavior is that when clicking on "Target" in the share, it should open the C:\Target folder on the workstation's C drive. Instead, the behavior I am seeing is that it opens the C:\Target folder on the server instead.

Link to comment
Share on other sites

4 answers to this question

Recommended Posts

  • 0

Well, thank you for the kind words!

 

You're absolutely right here. And thank you for the very detailed steps (this really helps us!) 

 

I can definitely reproduce this, and doing this on a non-pooled disk works as expected.   So it's definitely something to do with how we're handling the symlink on the pool  (we do have special handling for reparse points and symlinks, so that may be the cause here).

 

 

I've flagged this for Alex (the developer) to let him know about this. 

https://stablebit.com/Admin/IssueAnalysis/25953

 

But what version of StableBit DrivePool are you using, and what OS specifically (both for the server and client systems)?

 

 

 

Also, you could use "\\HOSTNAME\c$\Target" for the target, but I'm not sure if that will create network traffic for you, or not. 

Link to comment
Share on other sites

  • 0

Well, thank you for the kind words!

 

You're absolutely right here. And thank you for the very detailed steps (this really helps us!) 

 

I can definitely reproduce this, and doing this on a non-pooled disk works as expected.   So it's definitely something to do with how we're handling the symlink on the pool  (we do have special handling for reparse points and symlinks, so that may be the cause here).

 

 

I've flagged this for Alex (the developer) to let him know about this. 

https://stablebit.com/Admin/IssueAnalysis/25953

 

But what version of StableBit DrivePool are you using, and what OS specifically (both for the server and client systems)?

 

 

 

Also, you could use "\\HOSTNAME\c$\Target" for the target, but I'm not sure if that will create network traffic for you, or not. 

 

Thanks for the quick reply!

 

I'm currently using Drivepool v2.1.1.561, on Windows 2012r2 with most current updates/patches. Client is Windows 10 with the most current patches.

 

I hadn't thought of the \\hostname\c$\Target idea. I came up with another workaround (wrote a script to change the My Documents folder temporarily during program launch to the local destination, and then automatically back again after the program loads), but may try this and look at the network traffic load later.  Looking forward to if you guys come up with a better fix for hardlinks though.

 

Still loving Drivepool and Scanner. Looking into Cloud Drive too... very promising!

Link to comment
Share on other sites

  • 0

You're very welcome, and it's flagged as an issue, so we will definitely look into it. But it's probably going to be a very tricky bug (as anything involving links like this are very complicated). 

 

 

And yeah, the \\hostname\ option works. But don't use localhost, as that .... experiences the same issue. 

(and I tried the Volume ID and it didn't like that at all, which sadly, would have worked best)

 

 

 

 

And glad to hear that you're love the software aside from this one issue. :)

Link to comment
Share on other sites

  • 0

Sorry for the long delay here. 

 

 

Alex was able to take a look at this, and fix the issue.  And it as a particularly nasty issue. 

 

The latest build should fix this (2.2.0.762), but we have one person that has reported issues with the fix breaking symlinks, so I would try this on a test system to ensure that it works properly.  (we are following up with that issue, already)

 

 

 

that said, Alex (being the expert here) recommends using "junctions" here instead of symlinks, as these should function "better" (more of "how you expect").

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  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.

Loading...
×
×
  • Create New...