fattipants2016

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 h

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 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-plac

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 o

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.

I've been using duplicate commander for manual de-dupe for a few years, and it's worked great. If you suspect you suffered data loss / corruption during the failure, however, you might want to use something to actually hash your files. Comparing NTFS entries like modified date/time and file-size alone won't catch corruption, until you actually try to open the files.

Once upon a time, I had a soft link inside my Drivepool folder structure. It was pointing to a folder on a disk outside my Drivepool, that couldn't be migrated to the actual Drivepool without a great deal of reconfiguration and effort. The soft link has since been deleted, and replaced with the actual target folder that the link used to point to. Problem is, Drivepool keeps replacing the folder with the resurrected symlink (since they both have the same name.) I've tried deleting it, permanently deleting it (skipping recycle bin,) moving it first before deleting it. No

I found it. A particular piece of software I use implemented a 'recycle bin cleanup' feature that defaulted to on, and a cleanup period that defaulted to 7 days. I'm out about 3 days of head-scratching, $80 for a new SSD and several months worth of music and Doom mods I hadn't found time to organize.