h a l f b a k e r yViva los semi-panaderos!
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
NHFSD
Non-hierarchical file management system with properties of database with unlimited number of fields | |
The problem is not new. Read the well-written introduction on http://www.reenigne.org/computer/hierarchy.html
My solution is the file system, where every file is in one place (root directory), and every file has its ID much like in databases. (The filename would look like [ID][given filename].[extension])
Every
file would have an unlimited set of ID's embedded in its contents, which would actually describe the file.
A folder in this system would be a FILE with instructions either to find all other files, that have the FILE's ID or to find all other files that don't have the ID depending on users choice, and imitating logical operators AND and NOT in search engines.
To quicken the search, special lists of IDs should be created.
I think this solution doesn't require actually changing filing system and it could be implemented in already existing filing systems. It doesn't require changing file naming much.
One of the problems I see is as how to modify the operating system so that it presented a file for application execution separately from the codes used for file description and IDentification.
Because all the files exist in the "root directory", I suggest putting them ALL there appear in the root sorted by the popularity of ID amongst files in the disk. So a file, the ID of which is more popular, appears first to file with a less popular ID amongs all the files in disk.
Example: if a user has 10000 songs and 1000 pictures, then the FILE which has an instruction [find all the files with the ID of file 'song'] appears first to the FILE which has an instruction [find all the files with the ID of file 'picture'], but before the FILE which has an instruction [find all the files with the ID of the file 'document'], because songs and pictures are all documents. However if a user later downloads 9001 pictures and "places" them to file 'picture' (t.i. "folder" 'picture'), then the file 'picture' appears first to file 'song'.
The same manner to sort files should is used not only to sort files in "root directory", but also to arrange files when a user opens any file. (By saying "opens file" I mean "sorts other files by the file", and I do not mean "executes file with a specialized program").
Because [files with the same meaning] in remote systems now could have different IDs and names, [for example the files 004560015Music, 125000012Muzika, 000015005Muzik, 158420000Ongaku has the same semantic meaning, but different IDs] , I would propose world-wide conventions: let a subset of IDs have constant semantic meaning amongst the systems, let the ID=004560015 in all the systems to have the same meaning, so a japanese system will always recognize it as music and put it to the right place there: Ongaku.
This makes sense for multilingualism..:) In this system, everyone should be able to change the way ID=004560015 appears in his/her own system, but when other users browse your system, they see it in their way.
It would be very convenient in many aspects: Downloading files will usually not require pointing the directory, where to put them; say an MP3 file could be opened as directory and there you can find text for karaoke or stuff about the singer, instruments used and or much more...; you can understand all the obscure file names as you can read about them in them...
Andrew's website
http://www.reenigne...uter/hierarchy.html
Some thoughts on non-hierarchical filing system. [Inyuki, Oct 04 2004]
Revisin Control Software
http://www.componen...e.com/products/rcs/
Central repository for files with a check-in check-out system. I think this paradigm (if not this particular software) is well used elsewhere. [Jinbish, Oct 04 2004]
KDE
http://www.kde.org/
[quarl, Nov 10 2004]
WinFS
http://msdn.microsoft.com/data/winfs/
[quarl, Nov 10 2004]
[link]
|
| |
Please put move the link from the body of the text and make the link clickable by using the "link" button below the idea text. Also, please recategorise this to computer: database or some other, better category. |
|
| |
[my] see that is the difference between us. I would have done that link thing for free. |
|
| |
I wanted to comment that in years to come when we are searching for this idea, the name of it will be absolutely no help whatsoever <hint> |
|
| |
Hey, whoever knew vernon had japanese relatives? |
|
| |
I don't see anything wrong with using a hierarchical structure. They are intuitive and easy to understand (assuming that the classification system is well thought out). The main criticism appears to be based in the fact that storage space may be a problem. I'm not sure it is these days - if it is, I don't see that a new storage system is going to help. |
|
| |
Also, I think that the ID structure is counter - intuitive. By using an ID number you take away the'public' face of the information and trust to the observer to understand it - this is wholly dependent on the //world wide convention//. To assume that any convention is to be accepted is a step to far for me I'm afraid. |
|
| |
[Dimandja], I just want more convenient and faster operating filing system for us. Microsoft should also improve their software, shouldn't they also use this idea? |
|
| |
[Jinbish], in any hierarchical, no matter the classification system is well thought out, there will always be cases when a particular file will have to be stored in two places. It's not the matter of stoage space. It's the matter of inconvenient data structure. Unconvenient-to-remove duplicates, obscure filenames, questions as to where to place a file you're about to download and so on.. |
|
| |
Take a look at how par of this problem is solved in Google directory. It has the properties of the filing system I am thinking about, but not completely. |
|
| |
The links (*.lnk) also doesn't solve the problem. |
|
| |
How would the browsing a disk look like? |
|
| |
Actually when browsing, you could create a file-folder everywhere you want. Depending on where you create it, it automatically inherits the IDs of the path file-folders. After that, the file-folder actually appears in root and in all the file-folders the IDs of which the file-folder has. Many of the operations with files could be replaced with the swift operations with files' IDs and IDs in the "special lists". |
|
| |
"Moving" a file-folder from one file-folder to another would be merely a change of the description of the file-folder (not actually moving it on the disk). File-folders could actually be moved only accross the disks (from one disk to another, from one location to another). |
|
| |
Copying would have two meanings: either to give an additional ID (so if you copy a file-folder from one file-folder to another, the file-folder actually only acquires the new descriptional ID not losing its other embeded IDs) or creating a file with the identical contents, but with different ID. |
|
| |
Deletion would similarly have two meanings. Either you destroy the file-folder or you delete one or more its descriptional internal IDs, what makes it not appear in particualr file-folders. |
|
| |
[Inyuki], do you happen to know [blaise]? |
|
| |
[X2Entendre], unfortunately, no... |
|
| |
Why else do I need NHFSD-like system?: |
|
| |
When we use a disk, we are somewhat afraid that one disk might fail or be damaged. So we do backup copies of files. However later we may become somewhat unable to distinguish which version of the file contains all the necessary information. So we don't know what version to delete. And we keep creating up new files (copies). And we keep distributing them to disks not to lose the files (for example, HDD1, HDD2, CD, FlashDisk). What we need is a filing system, which collects them to one virtual place instead of lots of unfinished works distributed on our disks... |
|
| |
RCS is quite useful [link]. I use it when programming so that if I delete a line of code and my program dies on me under a massive pile of errors I can safely revert back. |
|
| |