Forum Posts Feed
file searcher with user-defined metadata columns (Windows)
< Next Topic | Back to topic list | Previous Topic >
Posted by 22111
Mar 2, 2021 at 08:46 AM
My remarks above also show the difficulties in switching from a db data set (physical CD collection, etc. where not needed db fields in some subcategories are simply filled with the default “null” values and don’t disturb) to a file-and-folder system (NTFS) where similar info (e.g. the “country” one), in different “sub-trees”, either finds itself on different “indentation” levels of the subfolders, or you would have to insert ugly, empty, intermediate “0” folders in-between - what nobody does to my knowledge -, and even then, the relevant subfolder DATA (i.e. further subfolders (here: A, E, F… for “country” but which would be the name of their PARENT folders, or then the files) would not be “identified” by their names (A, E, F…), but only (and to some degree only) in combination with their (common) direct parent folder (“C” or “Country” in this example); these are problems unknown to DBs…
You could try some redundancy, by repeating the parent-folder name (the parent-folder itself being needed to contain the subfolder in question AND its “siblings”) before the subfolder-name, e.g. the “country subfolders” would then be named CA, CE, CF instead of just A, E and F, or you would have to fiddle with \C\A\, \C\E\ and \C\F\; in any case, strict folder naming conditions would be needed in order to ensure “discretion”.
In other words, whilst my CD and DVD DBs for the physical things are unambiguous, my corresponding HDD collections seem “orderly” but in fact their current organization is not optimized since NTFS simply does not offer the necessary elements to do that.
Which brought me some other ideas but without a straight “heureka!” effect yet - btw, for servers and the like, MS has created a new file system, ReFS, but from what I have read about it, it has NOT been amended, compared to NTFS, in all their (now common) “it’s not more db-like” failings; in some other aspects, it’s even worse than NTFS in some respects, depending on your POV…
For the time being and unless I get further with one of my new ideas on the matter, I suppose that the above-described repetition of the parent-folder name in the sub-category folder name, with (e.g.) \c\ca\ instead of \c\a\ (but also instead of a technically possible just \ca\ without the \c\ “above” it!) seems to be a viable solution since far more extended systems than just a CD collection, the explicit naming possibilities would be much larger.
The inherent fail of NTFS, etc. being that any hierarchical position isn’t determined but by counting its position within the path, and any non-used position remains visible all the time if not actively suppressed for display - let alone the lack of any file identifier except for the - current, possibly ever-changing! - full path of the file…
(And so, yes, with lots of “\”-countings, again and again, things would be possible, but after all, there ARE attributes within the MFT, for every file, every folder, so why not also a 9- or 12-digit ID? But then, we all know Bill has got other hobbies, some even pretend vaccinating 8 billion down to just 1 or less being among them - which is pure slander of course…)
Posted by 22111
Mar 2, 2021 at 11:44 AM
I hadn’t thought about the fact that db records are in reference to the db they’re in, whilst folders and files are considered “floating”, between several computers, of the same person, among persons / departments in a corporation, even among persons and institutions world-wide. Okay, that complicates things a little bit.
There could be some two-or-three part ID (i.e. some “origin part” for the “creation device”, a dot, numbering-up for that device, another dot, then, if necessary only, the original string from the file-from-the-outside, i.e. the string - NOT a number, but alphanumeric and obviously of variable (composite) lengths - would be appended upon import onto the device (just as a - simpler - string would be created upon any file (and folder) creation on the device; files from the “corporation” would be considered “semi-internal”, a new (i.e. accordingly appended) string would only be assigned when the file is then modified in any way (automatic versioning, too), etc.
These are just some ideas of mine in less than 10 minutes after my realization my idea above (9- or 12-digit numbers) was not practicable except for private use, and such a concept could easily be refined to make it perfectly usable.
And yes, this would blow up the MFT just a little bit, and so what for modern systems (NTFS is from 1993 where the technical environment was totally different), and yes, an enhanced NTFS could manage both situations in parallel, assigning ID strings to new files and even existing ones in the system / corporation (of internal oder external origin), AND even to any “new” file coming “from the outside” and not bearing such an ID string already: It would process any such external string according to definite rules, and also assign/append further ID strings to external files created without.
At least WITHIN the organization in question, independently of its (current or future) size (from 1-person upward to 7-or-more-digit “seat” numbers), any folder and file would then be clearly identified.
Btw, such systems will come anyway, tax and other public administrations will make sure for it quite soon, and they will probably try to make those IDs discrete worldwide - which for file management reasons - the interests of physical or legal persons - obviously (and as hinted at supra) is NOT necessary.
As with everything, it’s all in the conception; the realization will then follow, forced upon in the end by THIRD-party interests…