fattipants2016

Well that wasn't terribly exciting. I expected DrivePool to complain or explode or something. The .covefs folders on a few of my drives had wonky permissions from being migrated between computers, so I'll bet that was the issue. It appears to have fixed my problem. Thank you!

I'm not brave enough to try that remotely, but I'll give it a whirl over the weekend. To be clear, just backup/blow up the entire contents of the .covefs folders, and let it rebuild?

I've encountered/solved this problem once before, but I don't remember what ended up working. I used to have a junction point E:\Downloads, which pointed to C:\Downloads. I deleted this junction point, and created a new one E:\Downloads, which now points to D:\Downloads. Every time I reboot my computer, the junction point gets replaced with one that points to C:\Downloads. If I create an empty folder E:\Downloads and reboot my computer, it also gets replaced with a junction point, pointing to C:\Downloads. If I delete E:\Downloads and reboot my computer, I can create a new folder E:\Downloads, which immediately gets replaced with a junction point. It's as if there's some 'old' drivepool metadata that doesn't get cleared out when I delete the folder/junction point. E:\ is my Drivepool. C:\ and D:\ are physical disks, which aren't part of the pool. Is there any way to tell Drivepool to do housekeeping, and blow out this old metadata for folders/junction points which no longer exist?

Thanks, I'll check it out and adjust accordingly. I'll bet one of my poolpart folders has inheritance turned on, and it's conflicting with the permissions inherited from the pool, itself.

Windows x64 20H2, Drivepool 2.2.4.1162 My pool has moved from computer-to-computer a few times, and the permissions have become a bit of a disaster. I've used the Windows Advance Security settings to take ownership, and 'Replace all Child Object Permissions' and ICACLS * /T /Q /C /RESET Either of these seem to fix things, for a while, but eventually certain folders stop respecting some/all of my permissions. I have several folders I can't write new folders to, for instance, for users other than the owner (admin.) This is made more complicated, because I have fairly complex Permissions set for my NAS users to let people read/write but no delete/modify. Inheritance is enabled for all folders inside the pool, but disabled for the pool folders on the physical disks. Is this correct? For instance, disks A B C comprise Drivepool D. All subfolders inside D have inheritance enabled, but A:\PoolPart.a62b8f52-8e51-4846-b369-2d00a5f20298 has inheritence disabled, as I'm assuming inheritence in this case would mean inherited from A:\ and not Drivepool D:\ The images should make this more clear. Thank you in advance.

Nevermind, it breaks things. It breaks them bad. Drivepool didn't respect the existing junction point, and created a folder with the same name, in the same location. Needless to say, Windows did not like this one bit nor did I. Don't be like me.

Is there any functional difference between creating a junction point on the Drivepool drive letter itself, vs. placing it on the physical disk directly? I don't like that their placement does not follow file placement rules, and I don't trust junction points existing on removable disks in case they fail to connect on a reboot. For instance, mklink /j E:\Downloads D:\Downloads (Where E:\ is Drivepool) vs mklink /j C:\drivepool\phsyicaldiskone\poolpart.6sdas68x4a65s4d6a\Downloads D:\Downloads (Where C:\Drivepool\Physicaldiskone is... physical disk one) I'm not trying to blow stuff up, but if it's all the same I'd like to dictate where the junction points get physically created.

I just added a new disk to my pool. I moved the handful of folders that all need to be on one disk (music, photos, etc. -- things I don't want sprawled across multiple disks) to the new disk. Then I installed the ordered file placement plugin, attempting to have drivepool fill this new disk last. (Basically, I want to save the new disk for the contiguous folders for as long as possible -- since drivepool's default behavior would be to fill this new disk, first.) It seems that checking the 'file placement rules respect real-time file placement limits' box breaks my file-placement rules, but ordered placement works. Unchecking this box causes my file placement rules to work again, but ordered file placement is no longer respected, and it starts filling my new disk again. Am I doing something wrong? Or is that just the way it is? I can work around this in other (manual) ways, but the ordered file placement plugin seemed like a nice hands-off solution.

I'm going to make a support ticket. I'll report back if I get any more information.

I'm attaching another screenshot to better illustrate the problem. When I rename the File Rabbits1.mp4 to Rabbits1~Rename.mp4 the file ID on the physical disk remains the same, but changes in the pool. Is there any way around this? I've tried disabling / enabling different 'performance' features in Drivepool, but none of them seem to stop it.

I'm attempting to use FreeFileSync to push a copy of my computer to an off-site server. FreeFileSync has the ability to track renamed/moved files, rather than simply duplicating them, or deleting/re-uploading the same file. This functionality relies on the NTFS unique file identifiers to match files that have been renamed/moved. The machine running Drivepool, however, seems to assign a new file ID each time the file is renamed or moved. Is this a known issue? Is there some sort of Drivepool file ID that supercedes/replaces the NTFS ID? I've attached two sample images of a successful rename/sync, and an unsuccessful example. Pointing FreeFileSync at the physical disks isn't going to be an option, so I'd really like to get this working.

Not quite real-time parity, but it's possible to trigger SnapRAID each time Drivepool balances with some clever scripting. I documented getting it set up, here.

I'm pretty sure I tried that. I ended up removing all disks from the pool, and starting from scratch. If it comes back at this point, I'll really be concerned.

You could force this behavior with file placement options (certain folders only on disks A + C, others only on B + C.) I think the duplication space optimizer should more or less achieve what you want by default, however.

Inside each physical disk that's part of the pool, exists a hidden folder named with a unique identification ID. Inside these folders is the same folder structure as the pool, itself. Your duplicated files / folders would simply be on the appropriate number of disks. They're not actually denoted as duplicates in any way. If files are now duplicated (that shouldn't) be, it may be enough to simply re-check duplication.