1.5a + drivepool?

[klepp0906]

So ive avoided drivepool after noticing its problematic with voidtools everything. this is probably the software of the gods. i saw a reddit post where someone was bellowing about how awesome 1.5 is turning out and between that and the discussions that have popped up here over the years about it, i hoped perhaps it was better positioned to work in tandem.

well, ive installed it and it can certainly index/search the mounted volumes, however the drives and the folders within appear useless. I generally find a folder I need an item from and use the context menu to direct an everything search to that location. Not possible at current and finding the specific folder im looking for across 30 disks all mounted with a drive bay number is not effective or ideal.

is this something that has a workaround other than what I just mentioned? (digging through mounted disks) or is it something thats literally unsolvable due to technological constraints?

just trying to determine if using drivepool is going to alter a major part of my workflow.

[void]

however the drives and the folders within appear useless.

Could you please elaborate.
Please give examples.
(please feel free to send to support@voidtools.com if you don't want to post here)

edit: You will need to add your volumes manually:

• In Everything, from the Tools menu, click Options.
• Click the NTFS tab on the left.
• For each drive in your pool:
  • Right click 'C:\Drives\Bay xx' and click Edit...
  • Change the path to: P:
  • Change the root to the root folder under C:\Drives\Bay xx (for example: PoolPart.01234567-0123-0123-0123-0123456789abcdef)
  • Click OK.
    Everything will create a custom volume entry.
  • Check Include in database.
• Click OK.

Mounting all volumes in P: will lead to duplicates.

I am aware there are issues with duplicates when indexing drivepools.
My current recommendation is to pass the results through the Everything Server:

On the PC with the drive pool:

• Start a new 'server' instance of Everything:
• Everything64.exe -instance "server"
• Setup an Everything Server.
  (If your main PC and the drive pool PC are the same, set Bind to interfaces to: localhost )
• Index all your drives as above.

On your main PC (can be the same PC as the drive pool)

• In Everything (the unnamed instance), add your Everything Server to your index under Tools -> Options -> Network Index.

Adding a network index will remove duplicated results.

[klepp0906]

hi void

i'm not getting duplicates, at least not as far as i can tell.... yet. (just set up drivepool today so frantically updating paths and apps and this was just one stop on that train)

here are some screenshots to better illustrate.

this is a pool.

1.jpg (18.21 KiB) Viewed 9574 times

here is me attempting to search the root, or the movies folder. no results

2.jpg (44.41 KiB) Viewed 9574 times

3.jpg (45.07 KiB) Viewed 9574 times

[klepp0906]

here is the same search but using the mount point instead (not preferred)

4.jpg (213.28 KiB) Viewed 9574 times

5.jpg (249.6 KiB) Viewed 9574 times

[void]

Thank you for the feedback klepp0906,

You will need to add your drives manually:

• In Everything, from the Tools menu, click Options.
• Click the NTFS tab on the left.
• For each drive in your pool:
  • Right click in the volume list and click Add....
  • Change the GUID to: ?\Volume{01234567-0123-0123-0123-0123456789abcdef}
    (where the GUID is one of the volumes in the pool)
  • Use powershell to list your volume GUIDs with the following command:
    GWMI -namespace root\cimv2 -class win32_volume | FL -property DriveLetter, DeviceID
  • Change the Path to: P:
  • Change the Root to: PoolPart.01234567-0123-0123-0123-0123456789abcdef
    (where PoolPart.01234567-0123-0123-0123-0123456789abcdef is the root folder on the volume)
  • Click OK.
• Click OK.
• Mounting all volumes in P: will lead to duplicates, hence the reason for running the index through the Everything Server (see above).

If you need any assistance setting this up, please send the powershell output from:
GWMI -namespace root\cimv2 -class win32_volume | FL -property DriveLetter, DeviceID
along with your drives under C:\Drives to support@voidtools.com

[klepp0906]

Thank you for being so helpful and accommodating. on top of that providing everything for free. hats off to you.

I'm getting ahead of myself as I havent thoroughly looked at the pros/cons/process of setting it up the server as it was late last night and now ive just gotten up and i'll be lucky to sound coherent in this post before i get some coffee in me.

i'll give it a go sometime today and report back though, god forbid i need to email about it lol.

are the doubles a product of the duplication that drivepool uses? what if one has duplication disabled? (i intend to set up snapraid instead)

also, assuming I get it set up under drive letter in the fashion you mention, does that mean I can delete all these mount points at that point?

1.jpg (58.91 KiB) Viewed 9548 times

[void]

are the doubles a product of the duplication that drivepool uses?
what if one has duplication disabled? (i intend to set up snapraid instead)

Yes and no, even with duplication off, you can still see multiple folders that will be merged on your P: drive.

also, assuming I get it set up under drive letter in the fashion you mention, does that mean I can delete all these mount points at that point?

If those volumes are already listed, then they cannot be removed.
Use the 'Include in database' setting to exclude them from your index.



Another option for de-duplication is to use the distinct:fullpath search function.

[klepp0906]

okay, i looked this over and adding them all seems easy enough. unfortunately when i ran that powershell command it lists all the guid's but all those disks have no drive letter associated so i dont know which is which.

any better way on the horizon? i could muscle through setting this up but my mind is going to a drive upgrade or failure situation where i'd need to find and note the guid and make this change each time. not impossible but cumbersome.

for now, i have to find a way to associate these guid's with the drive they correlate to lest i end up having to assign a letter to each drive and run it again lol

[void]

The volumes are listed under Tools -> Options -> NTFS.

You can right click -> Edit these volume entries.
When you make a change, Everything will make a copy of the volume entry.

It might be easier to:

• For each volume in the pool:
  • Right click 'C:\Drives\Bay xx' and click Edit...
  • Change the path to: P:
  • Change the root to the root folder under C:\Drives\Bay xx (for example: PoolPart.01234567-0123-0123-0123-0123456789abcdef)
  • Click OK.
    Everything will create a custom volume entry.
  • Check Include in database.
• Click OK.

[klepp0906]

yep, i was just coming to post that. man you are fast lol. no need for the powershell command when you can right click on the mounted disk > edit > select, and it gives you the guid right there. (some of them are already filled in)

any way to name the custom entry something other than Local Disk?

[klepp0906]

and would it be recommended (or at least not detrimental) to exclude the non (custom) P: disk thats listed there after i finish? i assume it wont remove it from the list so it probably accomplishes nothing i presume? just trying to keep things as clean and as organized as ill be able to after this mess

[void]

It might be easier to start fresh and remove your existing custom volumes and try the method above.

You can toggle Include in database for any volume and remove your custom volume entries.

[klepp0906]

big ask, but is there any way to script/automate this process?

I just posted another thread a few days back where it turned out to be user error that was causing me to be unable to find the path to/delete a folder/files within the $Recycle.bin on one of my pools.

What appears to have happened was a disk number changed (or i screwed up and just now picked up on it during the creation of all the custom index entries) which resulted in some wonkiness in the index and the aforementioned issue.

the more i think about it, things like changing drives whether it be due to failure (god forbid) or upgrading etc is going to be quite taxing as far as regaining parity with everything goes. i had left "remove offline volumes" disabled when i'd normally have it enabled, as i'd hoped it would at least help with the task of updating and catching things like this easily when/if they present due to the (offline) label.

unfortunately that didnt work, atleast in this case as nothing showed as offline anyhow.

ive removed and recreated all custom entries and the problem is gone, but that leaves me looking forward. would be a real shame if i have to purge and recreate this list every time something changes or have to wait to catch an issue to know it needs recreating to begin with. Not the smallest task with 22 drives pooled at current.

scripting something (if its even possible) is well above and beyond my ability so i figured id reach out here and see if there was in fact an "easy" way to automate or at least partially automate insuring the integrity of the custom NTFS volumes as both a preemptive and post-change sort of coverage.

[NotNull]

I read your post, but it is unclear to me what it is that should be automated? Something in Windows? In Everything? In Drivepool?

(With scripting, the most important "rule" is: Garbage in, garbage out. The better you define what you want, the larger chances are that it eventually will do what you want.

[kocane]

What am I doing wrong? The path appears like this.



My settings are like this:





I've disabled "include in database" on the "regular" volumes.

[void]

Please try changing the root (under Tools -> Options -> NTFS -> Z: -> Right click -> Edit) to:

PoolPart.xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxc73e


Currently, if the root is not found it is ignored.
I'll look into throwing an error when the root is not found.



Is this a nested drive pool?
If the above doesn't work, please try the following root:

PoolPart.xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx4c0c\PoolPart.xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxc73e

[kocane]

Please try changing the root (under Tools -> Options -> NTFS -> Z: -> Right click -> Edit) to:

PoolPart.xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxc73e


Currently, if the root is not found it is ignored.
I'll look into throwing an error when the root is not found.



Is this a nested drive pool?
If the above doesn't work, please try the following root:

PoolPart.xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx4c0c\PoolPart.xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxc73e

I'm an idiot. My screenshots clearly show me writing the wrong root path.

I adjusted it and it seems to work perfectly. A very nice solution to this issue, I must say.

Thanks for the help!

[kocane]

I had issue with duplicate results with this configuration, so I set up the Everything Server as described in one of your posts in here.

It works fine but it is now showing as offline. It's my understanding that it should start with the regular Everything Service, no? Must I do as described here, under "Server service"?

I use the 'regular' Everything Service to index my non-drivepool drives.

[void]

You don't need to setup the Everything Server Service.

This is only needed if you want to run the Everything Server without logging in.



If you wish to keep using the Everything Server, please try changing the service account to one with network access:

• From the Start menu, search for: services
• Right click Services and click Run as administrator.
• Right click Everything 1.5a and click Properties.
• Click the Log On tab.
• Check This account.
• Set the account and password with network access.
• Click OK.

Please also ensure the Everything Server is allowed through your firewall.

Please let me know if the issue persists.

[kocane]

Hmm, but should it be nessesary when it's all on localhost? Won't changing the service account away from SYSTEM mean that I might not be able to search out files where my regular user doesn't have access? (e.g. system files). If I run Everything64.exe -instance "server" again, my 'regular' instance started working again and the "remote" Everything index was no longer offline.

[void]

If its just for localhost usage, please don't use the Everything Server as a Service.

I should have been clearer with the setup.

Please run another instance of Everything that indexes your drivepool and hosts the Everything Server:

• Create a shortcut to your Everything64.exe
• Right click the shortcut and click Properties.
• Set the target to:
  "C:\Program Files\Everything 1.5a\Everything64.exe" -instance "Everything Server"
• Launch this shortcut.
• This will launch a new named Everything process.
• Setup Everything to index your drive pool.
• Setup Everything Server.
• Copy this shortcut to shell:startup

If you wanted to connect remotely from the same network, running the Everything Server Service as local system will have network access.
There's no need to change the service account.
If you did want to change the service account you'll need to use an account that has network access and admin privileges if you are indexing NTFS volumes.
-or-
Install the Everything Service and set the Everything Server Service to use a limited account with network access.

[kocane]

Ah, so the idea is that you run two seperate instances of Everything at the same time. For some reason I thought my "server" instance was just going to run under the "regular" Everything service as well. But this makes sense.

In order to run it more hidden, I made a service myself that launches Everything with -instance "server" arguments, so that it runs in the background hidden. It uses more memory than the regular Everything service but it seems to work.