Speaking of (external) NTFS drives here.
26 drive letters are not enough for me, since I have multiple external drives, most of them being backup drives, most of them of other external drives.
Thus, I have this system (my backup tool "understands" drive NAMES, so works without problems with this system):
FIXED drive letters (1-char, necessarily) k to z, for original data
Aleatorically-assigned drive letters before k (mostly g,h,i,j), assigned by Windows, upon connecting the drive, for backup drives.
The NAMES of the FIXED-letter drives K to Z are K1 to Z1.
The NAMES of the other external drives are K2 and K3, for the backups of drive named K1 (fixed letter k),
L2 and L3 for the backups of drive named L1 (fixed letter l), etc.
Now, in EV 1.5, the NAMES of the drives, additionally to their (currently assigned drive-LETTERS), are displayed in the list "Local NTFS volumes", also for currently NOT-connected drives, then with the mention "(Offline)".
Then, if I have a currently not-connected drive named K2, which LAST time it had been connected, had been assigned the drive letter j, searching in EV for "j:" will display its contents (greyed out, to indicate it's currently not available/connected).
BUT next time another backup drive, let's say S2, gets assigned the drive letter j while it's connected, the previous drive's j content is, or seems to be, lost, searching for "j:" will show the content of S2, not of K2 anymore (as expected, and given that I set ALL drive letters to be included into EV's database.
On the other hand, EV "knows" last time's drive j is in fact drive named K2, and its database insofar is independent from the MS table, so technically it would seem to be possible to make EV PRESERVE the "drive name K2" content, as long as the user doesn't connect a NEW "drive name K2" content (which would also to be connected, by Windows, as "drive letter j"), in which case the previous "drive name K2" part of EV's database obviously would be overwritten.
In the Search Options, I haven't found something like "drivename:...", or then, any 2-or-more-chars "drive letter" (e.g. "k2:", "some:", etc) would be recognized as drivename.
It seems that as for additional code necessary for this to be made possible, the main code would be:
1)
- check, upon user's setting "Settings for K1 (K:) - Include in database", if there is such a combination as in this example, and then
- include the drive NAME into the db (and NOT the combination, since the drive LETTER may be fixed OR aleatoric, so whenever there is a name, it's the drive name the user will want to have its content to be indexed, even independently of the drive letter)
2)
- maintain an additional db table drive-NAME (versus "last drive-letter"-"current-drive-letter", so as to recognize the "identity" of the drive even if currently it presents itself under a different (Windows-assigned) drive-LETTER as last time, and then
- EV would process all current Windows-generated info under the "new" drive-letter as incoming for the drive known by EV under its (not-changed) drive-name (which would slow down EV's response times just a little bit)
In other words, since EV never writes to, but just retrieves Windows table info, for data processing within its own indexed db, it should be able to "align" the not-changed drive name-info with the changed drive letter-info, and then process the "incoming" Windows info accordingly.
This way it would be able to maintain, in EV, a COMPLETE file repository, incl. - and permitting to look up files within, or compare with - even multiple backups or other drives to which a fixed drive letter could not be assigned.
Or is this already possible, and I may have overlooked the way how to do it, on the user's side?
Availability of index info also by drive NAME (instead of just drive LETTER)?
Re: Availability of index info also by drive NAME (instead of just drive LETTER)?
Thank you for the issue report 5410,
I will look into the issue.
Everything tracks volumes by volume name (\\?\Volume{01234567-8901-2345-6789-012345678901}), volume path (C:\) and volume root (SUBST drives)
I am aware of volume label tracking issues too... a fix is on my TODO list.
For now, please consider file lists.
I will look into the issue.
Everything tracks volumes by volume name (\\?\Volume{01234567-8901-2345-6789-012345678901}), volume path (C:\) and volume root (SUBST drives)
I am aware of volume label tracking issues too... a fix is on my TODO list.
For now, please consider file lists.
Re: Availability of index info also by drive NAME (instead of just drive LETTER)?
Thank you very much for the info, and I will look into the file list help for the meanwhile!
Just some considerations:
- I had consulted viewtopic.php?t=4296 = "Keep offline volumes in the index" but had not found relevant info in there.
- As said above, for my "original data" (i.e. not backups), I have FIXED drive letters, so when they are not currently connected, but some of the (non-fixed-letter) backup drives is connected, the latter does not risk to overwrite the fixed letter in my case, so does not risk to destroy its EV index,
- BUT this "fixing" of drive letters is not failproof it seems when it's done by Windows means. I do it by a paid program, "Zentimo", and which really "fixes" the drive letters, so that I don't ever have a problem with that, but trying to fix drive letters with windows means, I had to discover that the drive letters were not fixed, but were overwritten by other connections / drive-letter-assignments by windows - and most EV users will not have a special tool for this "fixing" drive letters, so (not in my case but in general EV use), there might be quite some problems arising in this respect, caused by Windows
- I also had looked - but forgot to mention that above - into the possible solution, "mount drive as folder", and then, "how to mount drive, not identified by drive-letter, but by volume label" (which I erroneously called "drive name" above, the "official" denomintion for that being drive/volume LABEL) (mount by junction point, etc.), but I had NOT found a solution how to do this, on my side, the - general - mounting solutions for Windows I found all being based on the assumption that the mounted drive's letter NOT changing in-between (whilst, ironically, I found two sources for Linux!
You're probably very deep into these matters whilst I can't but "browse" them, without understanding them, but just for reference, here's the list of the sources I "consulted":
Create new folder (on NTFS or ReFS)
open diskmgmt.msc, in there:
getting the volume label:
https://stackoverflow.com/questions/283 ... ndows-path
https://stackoverflow.com/questions/478 ... ive-letter
https://stackoverflow.com/questions/906 ... label?rq=3
https://stackoverflow.com/questions/119 ... rrect?rq=3
https://stackoverflow.com/questions/252 ... olume?rq=3
https://stackoverflow.com/questions/338 ... -line?rq=3
https://stackoverflow.com/questions/864 ... -file?rq=3
mounting a volume in general:
https://learn.microsoft.com/en-us/windo ... to-a-drive
https://answers.microsoft.com/en-us/win ... 92087f6424
mounting a volume by label (Linux only):
https://www.cyberciti.biz/faq/rhel-cent ... ion-label/ (Linux)
https://esite.ch/2014/04/mounting-exter ... its-label/ (Linux)
and volume labels in general (as an example of many):
https://www.lifewire.com/volume-label-2626045
And finally, here again, EV is THE reason to stay with Windows, a 1,000 thanks!
Just some considerations:
- I had consulted viewtopic.php?t=4296 = "Keep offline volumes in the index" but had not found relevant info in there.
- As said above, for my "original data" (i.e. not backups), I have FIXED drive letters, so when they are not currently connected, but some of the (non-fixed-letter) backup drives is connected, the latter does not risk to overwrite the fixed letter in my case, so does not risk to destroy its EV index,
- BUT this "fixing" of drive letters is not failproof it seems when it's done by Windows means. I do it by a paid program, "Zentimo", and which really "fixes" the drive letters, so that I don't ever have a problem with that, but trying to fix drive letters with windows means, I had to discover that the drive letters were not fixed, but were overwritten by other connections / drive-letter-assignments by windows - and most EV users will not have a special tool for this "fixing" drive letters, so (not in my case but in general EV use), there might be quite some problems arising in this respect, caused by Windows
- I also had looked - but forgot to mention that above - into the possible solution, "mount drive as folder", and then, "how to mount drive, not identified by drive-letter, but by volume label" (which I erroneously called "drive name" above, the "official" denomintion for that being drive/volume LABEL) (mount by junction point, etc.), but I had NOT found a solution how to do this, on my side, the - general - mounting solutions for Windows I found all being based on the assumption that the mounted drive's letter NOT changing in-between (whilst, ironically, I found two sources for Linux!
You're probably very deep into these matters whilst I can't but "browse" them, without understanding them, but just for reference, here's the list of the sources I "consulted":
Create new folder (on NTFS or ReFS)
open diskmgmt.msc, in there:
getting the volume label:
https://stackoverflow.com/questions/283 ... ndows-path
https://stackoverflow.com/questions/478 ... ive-letter
https://stackoverflow.com/questions/906 ... label?rq=3
https://stackoverflow.com/questions/119 ... rrect?rq=3
https://stackoverflow.com/questions/252 ... olume?rq=3
https://stackoverflow.com/questions/338 ... -line?rq=3
https://stackoverflow.com/questions/864 ... -file?rq=3
mounting a volume in general:
https://learn.microsoft.com/en-us/windo ... to-a-drive
https://answers.microsoft.com/en-us/win ... 92087f6424
mounting a volume by label (Linux only):
https://www.cyberciti.biz/faq/rhel-cent ... ion-label/ (Linux)
https://esite.ch/2014/04/mounting-exter ... its-label/ (Linux)
and volume labels in general (as an example of many):
https://www.lifewire.com/volume-label-2626045
And finally, here again, EV is THE reason to stay with Windows, a 1,000 thanks!