How can I have an online and offline index?

[cal]

I have many external hard drives that I will often connect and disconnect.

I think there was some way to make it display offline as grey but for my use case, preferably I'll run 2 instances of everything.

1 instance will have an index of all currently connected hard drives, 2nd instance will have an index of all offline hard drives.

If this was possible, do I need to make sure the offline index don't have conflicting drive letters?

[void]

Please try creating an Online and Offline filter:

• In Everything, from the Search menu, click Add to filters...
• Change the Name to:
  Online
• Change the Search to:
  !offline:
  
  (I use !offline: here instead of online: because !offline: will match volumes where the online status is unknown -where as online: will only match volumes Everything knows are online)
• Click OK.
  
• In Everything, from the Search menu, click Add to filters...
• Change the Name to:
  Offline
• Change the Search to:
  offline:
• Click OK.

Filters can be activated from the Search menu, Filter bar (View -> Filter Bar), Filter sidebar (View -> Filters), right clicking the status bar, filter macro or filter keyboard shortcut.
Filters can be organized from Search menu -> Organize filters.

online:
offline:



It is possible to run multiple instances.
I don't recommended multiple instances for your case.
Indexing just offline volumes is not possible.

You could setup your main instance to include only online volumes and your other named instance to include online and offline volumes.
Set your main instance to automatically add new volumes and automatically remove offline volumes under Tools -> Options -> NTFS
Leave both these settings unchecked for your named instance.
It's not very memory efficient to do this.

[therube]

If (& it seems) your offline are relatively static,
so wouldn't opening a separate instance, -read-only, work?

(And then, only periodically update your offline indexes, like when they happen to be online .
Likewise, you wouldn't want your offline Instance to include or automatically include your normal online drives, nor new added drives.)

Everything.exe -read-only -instance MY_OFFLINE_DRIVES

It's not very memory efficient to do this.

I understand duplication of work (by Everything), but otherwise, why & how so is it not very efficient?

[void]

-readonly might lead to stale index.
You would have to occasionally remove -readonly to update the index.

File lists is another option if the offline indexes don't change much.

I understand duplication of work (by Everything), but otherwise, why & how so is it not very efficient?

The work done (CPU usage) would not be noticeable.
Duplicating indexes would waste a bit of RAM.
The extra RAM usage shouldn't matter much if you only occasionally run the offline instance.

[SolarTheory]

I'm currently in a similar situation where I have a bunch of offline volumes and network index in the database file. The data is essentially static and I do not need it loaded most of the time. I want to move them to file lists to reduce the current massive memory footprint and database file size, but I am concerned about losing some indexed data in the process. I had various custom properties indexed at the time they went offline, but I don't remember exactly which ones. I want to avoid dumping the entire list of Everything properties + Windows properties to a file list, just to be sure I got everything.

• Is there a tool or command to query the database for a given offline volume to determine the actual properties/columns that have been indexed with data?

• When exporting file lists, will Everything export all data records of all visible columns of properties that were added to the index (via Options > Properties)? I seemed to recall in issue with exporting data to file lists in the past because I had not scrolled down to force Everything to "retrieve" the data first. Not sure how this applies to offline data.

• EFU vs. CSV to archive static indexes that I will occasionally load into Everything. Is there a preferred format (I'm guessing EFU is preferred for this)

Worst case, I dump all properties to a file list and use PowerShell to parse it and figure out that has data and what does not and delete empty fields via the PowerShell script.

[Herkules97]

I have many external hard drives that I will often connect and disconnect.

I think there was some way to make it display offline as grey but for my use case, preferably I'll run 2 instances of everything.

1 instance will have an index of all currently connected hard drives, 2nd instance will have an index of all offline hard drives.

If this was possible, do I need to make sure the offline index don't have conflicting drive letters?

Is memory the reason you don't want to run just one? As in saving the RAM by only keeping on the instance with known online disks?
If you use NTFS on all the HDDs, then EBV will know they're offline if you add them as that.

If you use the same drive letters, you will have to filter in some other way but I presume you already know this.
Can't do E:\ if you want to only find one of 2 E:\ devices. There is an index number inside of Tools -> Debug - Statistics for that.
The search fsi:[number] will find only files for that, all monitors gets an index number.
If you have lots of folders in an instance, it can take a while to load this list every time. Another reason it's better to sub-folder so you don't have to use fsi:.
As long as you've named them something to stand out, you can know which is which.
The easier however is to put everything in a sub-folder. It's what I started doing with all new HDDs and old ones that still work.
So now I can have B:\B1 and B:\B2. No need to know the FSI at least for any that this applies to.
I think you might be able to make a filter for this if you don't make sub-folders. For example naming the macro B1: or whathaveyou for the first B:\ and B2: for second and the search is fsi:1 and fsi:2 or whatever. Maybe I should do this myself for broken HDDs in my monolithic instance, hmm..

[void]

I had various custom properties indexed at the time they went offline

Make a backup of your Everything.db
You can always load old Everything.db files from File -> Open File List.. then export to EFU, CSV etc..

Is there a tool or command to query the database for a given offline volume to determine the actual properties/columns that have been indexed with data?

There's no command line tool to do this.
This information can be found in Everything under Tools -> Debug -> Statistics.
You can query the known properties with ES (the command line interface to Everything).

When exporting file lists, will Everything export all data records of all visible columns of properties that were added to the index (via Options > Properties)? I seemed to recall in issue with exporting data to file lists in the past because I had not scrolled down to force Everything to "retrieve" the data first. Not sure how this applies to offline data.

Only shown columns are exported.
Make sure all your indexed properties are shown as columns before exporting.

All indexed information is exported.
Only previously gathered unindexed information is exported.

To gather all unindexed information before exporting:

• Select all files (Ctrl + A)
• From the File menu, click Read Extended Information.

(Everything will do this automatically if you enable Tools -> Options -> Advanced -> gather_properties_on_export)

All indexed information in offline files will be exported.
Gathering unindexed information will do nothing for offline files.

EFU vs. CSV to archive static indexes that I will occasionally load into Everything. Is there a preferred format (I'm guessing EFU is preferred for this)

EFU is preferred because it will use the full Filename and full resolution timestamps.
CSV exports information as shown, so Name+Path with timestamps in seconds.



efu_filetime
efu_folder_append_path_separator
gather_properties_on_export
csv_type
csv_filetime

[therube]

-readonly might lead to stale index.
You would have to occasionally remove -readonly to update the index.

(Depending on circumstances), but what I've been doing is to periodically, physically copy the .db from updated index to -read-only Instance, & then restarting the -read-only instance (which essentially updates the -read-only index).

There is no interference in the copying from updated index, & the overwriting of the -read-only .db.

I run this from my -read-only Instance:

Code: Select all

:: BU-HOME.bat - back up Everything 15 .db for use elsewhere
:: SjB 03-15-2024

@echo off

:: save to DISK (rather then just RAM) -instance 15's .db
:: takes a moment, so throw in a pause, & wait, a few sec

everything.exe -instance 15 -save-db
ECHO Saving .db to disk...
pause

SET EVERYTHINGDIR=C:\DEV\Locate\15.1413

COPY /y %EVERYTHINGDIR%\"Everything-15.db"        "Everything-HOME.db"
COPY /y %EVERYTHINGDIR%\"Search History-15.csv"   "Search History-HOME.csv"
COPY /y %EVERYTHINGDIR%\"Run History-15.csv"      "Run History-HOME.csv"

:: skipping Everything-15.ini as i make changes to the layout in HOME version that i want to keep
::    COPY /y %EVERYTHINGDIR%\Everything-15.ini       Everything-HOME.ini
ECHO Files copied...
pause

:: update (freshen, actually)
ARJ32 f E-HOME.arj -jt1 -g?
pause

And a different scenario. Here I'm using the -restart switch with the -read-only Instance.

Code: Select all

Everything -instance 15 -save-db

sleep 3
gecho -n -e \a

COPY /y "Everything-15.db"        "C:\DEV\Locate\MULE.1402\Everything-MULE.1402.db"

:: .db is "static", "not locked", if you will, not written until quit (or -save-db)
:: so in that respect, can simply be overwritten - at any time, & it will remain,
:: static... until.  & if you've opened Everything -read-only, the .db will forever
:: be static, unless you manually "update" it (which this will do...)

:: then, on the MULE end, it is only a matter of restarting Everything, which will
:: then load the .db, some static, or some manually updated version, such that its'
:: "-read-only" mode has been "updated", though not by the -instance MULE, but
:: rather "externally", "manually" (by virtue of -instance 15's -save-db...)

:: & with that, Everything -instance MULE -restart
:: & with, session_store_restore_on_first_new_window=1, set (in .ini)
:: will quit/restart Everything, restoring the Session, "manually" updating...



:: -save-db      will issue a command to the existing Everything.exe to save the
::               database to disk - in the background.
:: -save-db-now  will save the database to disk and not return until this completes.


:: so... i could have used:

:: Everything.exe -instance 15 -save-db-now

:: & avoided having to do the sleep, as -save-db-now would have assured i wasn't
:: copying files before it had finished saving the .db to disk