Jump to content

Alyred

Members
  • Posts

    3
  • Joined

  • Last visited

Alyred's Achievements

Newbie

Newbie (1/3)

0

Reputation

  1. Hi all, While Drive Scanner has worked well for me, it's always bugged me that we can't read SMART information when the controller is set to RAID mode - Setting up a RAID-0 stripe on my NVME drives puts the entire controller into RAID mode. CrystalDiskInfo manages this through a plug in that works well, any chance we can get Drive Scanner to work for that for AMD X570, B550 and Intel chipsets? Or... is there a way to do this that I'm completely missing?
  2. 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!
  3. 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.
×
×
  • Create New...