XYplorer Beta Club

Why not use the serial number of the drive instead?

highend wrote:Why not use the serial number of the drive instead?

I hope the serial number is used for this program everywhere where it matters ( tags, labels, caching, etc... ) otherwise those of us with multiple drives, or network drives, or those of us that use hot-swap drive caddies will end up having files tagged on incorrect drives if the drives share a similar file structure...

Currently not, but a good idea.

PS: The disadvantage of adding the serial number would be that currently all those data are ultra-easily readable for humans and machines. With the serial the format would become more complex. Also processing would become (slightly) slower, and the caches (slightly) bigger.

Actually, drive letters are A-Z... You could build a table using 0-9 ( and other single-chars up to 255 or so if necessary ) and store the cached data 0:\<path> instead of C:\<path> and when you lookup the data, 0 translates into serial number...

That would be a simple way to minimally increase the size of cache ( by adding the overhead of a single-char plus the length of the serial number, and the query of loading that array into memory and reading the serials from currently inserted hard-drives plus a callback when one is inserted or removed and also being able to translate that char to serial to drive-letter for friendly output ).

That would be just one of many different methods you could use to ensure the size of the cache remains the same size ( negligible difference of [ if you use 1-char up to 255 - upper-case A-Z ie 26 or 52 so 203 basic chars available for that many drives -- although you could even use upper and lower a-z if you translate them ] so 255 bytes multiplied by the serial number in chars as bytes to see, roughly, the amount of additional data you'd need to store if someone actually has that many drives.. in the event of going over that amount you could start using double-chars, or simply use digits... )

If you switch to <serial> instead of drive letter don't do dual lookups (with an extra table that stores associations). Very bad on the user's side (to read and interpret data in tag.dat). Apart from that it would be a big step forward for portable tags. Maybe a special test version (once implemented) would be a good thing. I'd run it through a few tests regarding lookup speed, rereading database speed, etc. to see if the speed difference is neglectable

It'd basically be a hash table setup for what I'm suggesting.. file-io is the most expensive thing on pcs currently, now coming down in cost with SSDs, but after the serial is read from the drives and the drive-letter returned, you'd just have to link it to the stored id-letter/char to read the data... it'd be a O( 1 ) swap meaning the expense is negligible and not noticeable..

Filehero wrote: I'm still thinking about a feasible way for my cache-locations-white-list. For obvious reasons it's quite ugly to use the current (global cache-on plus) tweak for reversion of logic (though it's a common XY pattern), something like

Code: Select all

CacheFolderSizesExclude=!D:\FolderToCacheFolderSize

The wood, the trees, the heat, the , whatever: ARGHHHH

Before my white-listing cry it was already (that is, 2 weeks before...) outlined here. And this is my simple inverted white list (aka black list) which was possible all the time!

Just to "close" this case and give a maybe helpful hint to others.