Shane

Looks like you need to un-tick the first and/or third checkbox in the "File placement settings" section near the top of that picture?

What level of reinstall did you do for Windows?

Fair enough. Hmm. In the meantime, I did a quick search and you can use a DISKPART script to make a disk volume read-only or writable via the command line, for example: diskpart /s z:\make-readonly.txt and diskpart /s z:\make-writable.txt where make-readonly.txt would be a text file consisting of select volume driveletter attributes volume set readonly exit and make-writable.txt would be a text file consisting of select volume driveletter attributes volume clear readonly exit where "driveletter" would be the drive letter of your cloud drive (e.g. "select volume p"). Give it a try on a test cloud drive? It doesn't work with DrivePool, but maybe it will work with CloudDrive?

Moved to intended section. If noone's able to help, this looks like the kind of issue that could benefit from a support ticket. Have a great day!

Note that you don't need to deactivate machine A's license as described in the above linked post (unless you plan to stop using DrivePool on that machine).

You could use the Contact form to submit a feature request to Stablebit for such a command line / scheduled operation, but I'm not sure how effective such a thing would be; if your computer can be scripted or scheduled to toggle the read-only state of a cloud resource, so can any ransomware potentially be written to do the same. Edit: I can see some value in a "lock this drive (make it read-only) until I manually enter a password to unlock it" command.

Perhaps try uninstalling and reinstalling DrivePool, with a restart of the computer inbetween. It might be needed to get the DrivePool file system drivers talking with Windows again?

The way DrivePool's duplication works there isn't really an "original" and a "copy" of a file, the file just exists on two or more drives at the same time (exception: if real-time duplication isn't turned on, the file starts off only on one drive until the next scheduled duplication pass). You can use the Ordered File Placement balancer (OFP) to fill drives in a pool in a certain order, so long as there's room to do so. So a file might end up on drive 1 and 2, or 1 and 3, or 2 and 3, etc, but OFP can't ensure a file exists on two particular separate groups of drives. OFP can use separate priority lists for non-duplicated and duplicated files, so you could have non-duplicated and duplicated files filling the drives of a pool in different directions. You can use the Drive Usage Limiter balancer (DUL) to place files only on certain drives, so long as there's room to do so. Like the OFP, the DUL can be set to restrict non-duplicated and duplicated files differently but can't ensure a file exists on separate groups of drives. If however what you want is to ensure that a group of drives never holds the only copies of your files? Use a super-pool to duplicate the files (and/or have backups).

That would work (presuming you have enough free space). Alternatively you could use a USB drive dock to connect and add one of the new drives before removing one of the old drives, then repeat the process with the other new and old drives. Though this assumes you have a spare USB port and a USB dock to plug into it. There's also manual tricks you can use to more quickly (still takes a while) replace pooled drives with new ones, but they require a certain level of "knowing what you're doing" in case anything doesn't go according to plan, involving copying from inside the pool drives' hidden PoolPart folders.

That's basically what DrivePool does, and the pool drive can be shared over the network, so it sounds like it would be suitable for you!

Not that I know of. You could suggest it via the https://stablebit.com/Contact form?

Hi Steve, please use https://stablebit.com/Contact form and choose "An issue with licensing" for what needs to be contacted about.

You could try forcing a remeasure: Manage Pool -> Re-measure. Otherwise, you could take a look at Manage Pool -> Balancing and look through the Settings, Balancers and File Placement tabs to see if anything looks responsible. If all of the above fails, and you don't mind having to retweak anything to your preferences, there is also (cog icon) -> Troubleshooting -> Reset All Settings which will reset all of the balancing and application preferences to default values while leaving your pool(s) intact.

Hmm. How long is long? Or (wild guess) the long directory/filename contains unusual/mangled characters which the duplication process can't parse correctly? Do the drives in the pool all pass a "chkdsk" command?

Any luck with (cog icon)->Troubleshooting->Recheck duplication? You could also try a tool like Everything from Voidtools running as administrator to see if there are any hidden system files in the poolpart folders (other than the [Metadata] subfolder). "Other" usually refers to data stored on the pooled drives outside of the pool - e.g. if you've added drive "F:" to a pool, anything in F:\PoolPart.guid is inside the pool while anything in (for example) F:\SomeFiles\ is outside the pool - as well as all the standard filesystem metadata and overhead that takes up space on a formatted drive. For example, the hidden protected system folder "System Volume Information" created by Windows will report a size of zero even if you are using an Administrator account, despite possibly being many gigabytes in size (at least if you are using the built-in Explorer; other apps such as JAM's TreeSize may show the correct amount).

To clear the Driver Verifier entries, you can open a Command Prompt and enter the following: Verifier /Reset

1. I believe that's normal and expected. 2. This is a quirk of how the "partition" geometry is seen by Windows. If you look at the volume section, you can see Windows can still see the true "volume" capacity. 3. I believe SB decided to prioritise DP's reliability and performance over the additional code necessary to reflect the impact of duplication - especially since it is possible to set pool duplication per-folder and to use a disk for both pool and non-pool storage, which would make it impossible to accurately show how much free "post-duplication" space remains. Pretty much the "collected location" is these forums? There's also the dev wiki.

In the "what happens when I write to the pool" scenario, I imagine it would depend on whether you have duplication set to real-time or not; if it's real-time it will immediately notice it can't write to multiple drives, while if it's deferred it will only run into the problem when it does the nightly duplication pass. In the "what happens if I remove a bad drive" scenario, the pool should keep functioning but warn you that it can't duplicate the files due to insufficient space. At worst you would have to try again and this time tick the "Duplicate files later" box in the Remove options to proceed.

It may work? Stop the "Stablebit DrivePool Service" service beforehand, rename the folder, start the service again afterwards. Be prepared to Undo the rename if it doesn't work. Though honestly if there's no desktop.ini file involved I don't know how it's happening in the first place.

There are at least two methods to do this. Simplest method would be to create a separate pool for each grouping of disks (e.g. "enclosure A disks" and "enclosure B disks") then create a super-pool consisting of those pools and turn on duplication just for the super-pool (my preference). If you want more granular control, you could use the Ordered File Placement balancer and stagger the Duplicated placement priority with disks inside and outside the enclosure. You could also combine the two methods (e.g. use a super-pool for duplication and then use the OFP balancer for fine control of each of the sub-pools). Since the balancer algorithm can occasionally run into issues, if you just want guaranteed fire-and-forget I'd go with the first method.

Yes, data outside the hidden pool folder is untouched.

Hmm. I vaguely recall this has come up before. Basically the "total" (unduplicated + duplicated + free remaining) in DrivePool's gui is based on the file sizes rather than the size they take up on the disk, which aren't necessarily the same due to the way NTFS works. DrivePool is still (as you can see from the top left of the tooltip) aware of the actual size of the physical drive. Aha, found it: TLDR the DrivePool uses "file size" rather than "size on disk" for some of its calculations, and this is reflected in the GUI. If you want DrivePool to recalculate these just in case, you can use the GUI's "Manage Pool" -> "Re-measure..."

If I had make a wild guess, it's possible that the Windows 7 Backup is assuming the destination is a physical drive and attempting to use VSS or special NTFS metadata operations which aren't supported by DrivePool. For whatever it's worth, I'm using Veeam for my own system image backups and haven't encountered that issue.

gtaus is correct: if chkdsk unmounts the drive, Drivepool will notice the drive is missing and change the pool to read-only until the drive is remounted at which point the drive will merge back into the pool and the pool will become writeable again it is unlikely but if chkdsk goes wrong and effectively formats the drive, the pool will need to be told that the drive is permanently gone and whatever was only on that drive will be lost it is also unlikely but if chkdsk goes wrong and mangles the drive contents but the poolpart folder itself is intact enough for drivepool to recognise it, drivepool will attempt to merge it back into the pool which may result in conflicts Protips: use Windows Disk Management to take one of the pool's other good drives offline first, that way your pool will stay read-only until you put the good drive back online and you can thus check the suspect drive for yourself whether chkdsk did its job properly before you toggle the good drive back online to make the pool writable again if you don't already have backups, you can also take advantage of this read-only state to backup the current contents of the hidden poolpart folder on the suspect drive to somewhere else before running the chkdsk

I'd recommend adding the new drives or creating a new pool with them, and then moving the contents inside each old poolpart to the new poolpart - minus any system folders - rather than attempting to moving the poolparts themselves. Trying the latter may result in Windows complaining about the hidden system folder ("System Volume Information") that Windows creates within the poolpart folder. Alternatively, if you've got any spare USB ports, you could use USB drive dock(s) to help perform the migration? Preferably USB3, because USB2 would take a lot longer. Especially, don't try to cut and paste poolpart folders on a machine that has DrivePool installed. I just tested that to see what would happen, and ended up having to delete and recreate the physical drive partitions to get DrivePool to recognise them again.