Done Extended directory search database

[Steve Fabian]

1/ Desire a control to change the default to not updating the database by ANY command.

2/ For portable drives (and pseudodrives) it would be useful for their segment of the database to reside in their own root directory, WITHOUT driveletter, because even on the same system they may be plugged into a different USB port at different times, thus responding to different driveletters.
--
Steve

 

[Kachupp]

2/ Each volume has its own serial number It doesn't get anymore specific
than that.

I have a script that does that specifically for USB plug and play It
detects that very "difference"
It isn't tricky at all with a btm, can't be too hard for the OS/shell
either. Hello plugin Vince! :)


-----Original Message-----
From: Steve Fabian [mailto:]
Sent: Thursday, 30 June 2011 9:55 a.m.
To: [email protected]
Subject: [Suggestions-t-2957] Extended directory search database


1/ Desire a control to change the default to not updating the database
by ANY command.

2/ For portable drives (and pseudodrives) it would be useful for their
segment of the database to reside in their own root directory, WITHOUT
driveletter, because even on the same system they may be plugged into a
different USB port at different times, thus responding to different
driveletters.
--

 

[Steve Fabian]

From: Steve Fabian
| 2/ For portable drives (and pseudodrives) it would be useful for their
| segment of the database to reside in their own root directory, WITHOUT
| driveletter, because even on the same system they may be plugged into
| a different USB port at different times, thus responding to different
| driveletters.

From: Kachupp
| 2/ Each volume has its own serial number It doesn't get anymore
| specific than that.
|
| I have a script that does that specifically for USB plug and play It
| detects that very "difference"
| It isn't tricky at all with a btm, can't be too hard for the OS/shell
| either. Hello plugin Vince!

When used on a single system using different ports, this would be perfect. But it would require that my memory stick be cataloged on each system on which I may use it, leaving behind a junk file when I leave. Furthermore, since the serial number is just a 32b integer, there is no assurance that you don't have a disk with the same serial number as one of mine.

Another point about my scheme: when you rebuild your system, adding a NEW drive as C:, you need to recatalog everything. My scheme (each drive has its own index file) would not require that. Considering the availability of memory, I would use for the directory database a method similar to the one for global aliases, etc. - when a drive becomes accessible (by TCC start-up OR by plugging in OR by network mapping) TCC should read its index file (WITH drive letters added as applicable at the moment). Any updates to the table (explicit via CDD /S or implicit by directory creation or deletion using a TCC command which is allowed to update the datase) are written to the device's index file immediately. When a device becomes inaccessible (unmapping or turning off power of a network drive, unplugging a USB device, etc.) its entries would be removed from the live database table. BTW, this method would retain the ability to temporarily add read-only devices (CD-ROM, DVD-ROM) to the database, with the additional benefit that when a different CD is inserted into the drive, the previous one's directory database will not be used to access it.
--
Steve