Filing system structure

dmsmith · September 2019

I know there are Cabinet files on Windows, but I was wondering why don't the Windows developers adopt a new type of file structure which mimics traditional filing methods. So one would have Cabinets which would be a kind of high level structure, you could create these on your 'desktop' and give them names then inside each Cabinet you could create Drawer filing structures, and inside those Folder file structures. You could even have higher level filing structures than Cabinets though I don't know what they would be called.

So good idea or not?

mik3d3nch · September 2019

Theres nothing to stop you from building a hierarchical filing system using folders and renaming them according to your chosen levels and then treating each one like a filing cabinet with other folders for drawers and still more for files.

Or perhaps using a good relational database and constructing it along those lines if thats what turns you on!

I'm no expert - everyone knows that - but I'm glad that we have the system we do in Windows especially now Win 10 prevents people like me from gaily deleting system files or corrupting them by being careless with what went where.

Frankly what you suggest strikes me as a bloody nightmare! At least a lazy, scruffy, disorganized sod like myself can usually find his stuff and not damage anything vital - not for lack of trying.

Scottie_uk · September 2019

Conceptually a cabinet, and draw as a same concept as a folder. Just as a cabinet can contain draws that contain folders.

A folder called Cabinet1 could contain a folder called Draw1A which can contain any number of files. So really, if you really wanted cabinets and draws and folders you still can.

Some of the early GUI systems even drew disks as cabinets, i.e. a C drive was shown as a cabinet. Digital Research's GEM desktop, as used in the Atari ST, had a similar concept.
http://blog.netting.org.uk/wp-content/uploads/2019/03/ST-GEM-Desktop-1920x1080.png

1024MAK · September 2019

Yes, and if I remember correctly, some replacement desk tops for the Atari ST/STFM/STE etc. allowed you to use custom designed icons. So you could change the disk drive or folder icon to your own design :)

Mark

i love the z80s · September 2019

I'm not sure what advantage such a system would have! I mean it's more complex and more limited than just plain folders inside folders. What happens when you want to move a cabinet inside another cabinet? Does it refuse or just magically turn it into a drawer/folder/whatever?

dmsmith · September 2019

Yes I know its basically the same as folders within folders, but it mimics real life filling systems more closely. You would not be able to drag a cabinet inside another cabinet, so you would just have to think out first how to arrange your files - which isn't necessarily a bad thing. You could of course move files and folders from one drawer or cabinet to another.

Re the Gem Desktop - yes I was thinking about those Disk Drive Icons when I was posting. Also was thinking of the filling cabinet icons from the Fourth Protocol Game.

serveimage?url=https%3A%2F%2Fupload.wikimedia.org%2Fwikipedia%2Fen%2Fthumb%2F6%2F6d%2FThe_Fourth_Protocol-The_NATO_Documents.png%2F220px-The_Fourth_Protocol-The_NATO_Documents.png&sp=ea51f0f450c087d245a8b193c8f5568a&anticache=926872

serveimage?url=https%3A%2F%2Fupload.wikimedia.org%2Fwikipedia%2Fen%2Fthumb%2F6%2F6d%2FThe_Fourth_Protocol-The_NATO_Documents.png%2F220px-The_Fourth_Protocol-The_NATO_Documents.png&sp=ea51f0f450c087d245a8b193c8f5568a&anticache=926872

guesser · September 2019

dmsmith wrote: »

but it mimics real life filling systems more closely.

Real life uses computers to store information now, because it's better.

dmsmith wrote: »

which isn't necessarily a bad thing.

Yes it is, it's a pointless restriction.

1024MAK · September 2019

guesser wrote: »

dmsmith wrote: »

which isn't necessarily a bad thing.

Yes it is, it's a pointless restriction.

Agreed

It has always bugged me how short sighted some designs are. Take computer mass storage systems. Why did it take so long to come up with a long file names system? Why do HDD formats have to be rubbish simple systems where ALL the blocks have to be the same size? Why did it take ages before the maximum number of files/folders/directories became a respectably large number (and why have a system which limited it in the first place?)

And of course, often we are still coming up against the three digit file extension problem, where there are countless applications that all use the same three digit file extension, so of course, Windows helpfully opens the wrong application, which then eventually throws up an error message X(

So one thing is for sure, I am not at all keen on any new limitations...

Mark

AndyC · September 2019

dmsmith wrote: »

Yes I know its basically the same as folders within folders, but it mimics real life filling systems more closely. You would not be able to drag a cabinet inside another cabinet, so you would just have to think out first how to arrange your files - which isn't necessarily a bad thing. You could of course move files and folders from one drawer or cabinet to another.

This is known as skeuomorphic design, where you mimic a real world design rather than introduce something completely new. It has some benefits to entirely new users, because they can be more familiar with the concepts and don't need to learn new things. However it tends to be unnecessarily limiting over an authentically digital design, which you can see when you start running out of words for things that would indicate groupings. Even Apple, who were perhaps the last big advocates for skeuomorphic design, have largely moved away from it in their apps.

1024MAK wrote: »

And of course, often we are still coming up against the three digit file extension problem, where there are countless applications that all use the same three digit file extension, so of course, Windows helpfully opens the wrong application, which then eventually throws up an error message X(

But that just a weird anachronism of human behaviour. Extensions haven't had to be three letters since the introduction of long file names and yet software developers keep gravitating towards that. There isn't any technical reason that you couldn't have a collection of .SpectrumTape files rather than a bunch of .Tzx files, for example.

guesser · September 2019

Or just get rid of them entirely and not store type metadata in the name field.

rich_chandler · September 2019

guesser wrote: »

Or just get rid of them entirely and not store type metadata in the name field.

I'm guessing that's because people like visibility.

AndyC · September 2019

guesser wrote: »

Or just get rid of them entirely and not store type metadata in the name field.

The problem is that "plain text" files were already prevalent, but lack anywhere to store any kind of metadata. That means it has to sit externally somewhere. Using the name was convenient because existing methods of file transfer, such as email, ftp etc really only understand two concepts - a stream of bits which make up the contents of the file and a name.

This was always a problem for old school Macs, which stored metadata about the file type and creator app as four character codes in a separate part of the filesystem (a resource fork). Not only did transferring files cause issues but it's also why Macs tended to create a bunch of messy hidden folders every time they connected to a file share, because they needed to fake file system features the type identification relied on. Eventually Apple did the sensible thing and just accepted we're kind of stuck with extensions.

Backwards compatibility is often at the root cause of "weird" decisions like this and is often not easy to engineer out without breaking things people rely upon.

1024MAK · September 2019

I’ve got no problem with maintaining backwards compatibly with existing file types. The problem is the lack of forward movement by most people/companies.

And to be honest, I don’t see any point in messing around trying to find a way to insert metadata into simple file formats, like plain text files, simple binary files, hex files etc. For all these, using a longer extension name is the most practical. As long as it’s not just the simple three digit file extension...

Of course, now that there are many different flavours of operating systems, it would take some cooperation between the different parties.

Mark

Lee Fogarty · September 2019

AndyC wrote: »

guesser wrote: »

Or just get rid of them entirely and not store type metadata in the name field.

The problem is that "plain text" files were already prevalent, but lack anywhere to store any kind of metadata. That means it has to sit externally somewhere. Using the name was convenient because existing methods of file transfer, such as email, ftp etc really only understand two concepts - a stream of bits which make up the contents of the file and a name.

This was always a problem for old school Macs, which stored metadata about the file type and creator app as four character codes in a separate part of the filesystem (a resource fork). Not only did transferring files cause issues but it's also why Macs tended to create a bunch of messy hidden folders every time they connected to a file share, because they needed to fake file system features the type identification relied on. Eventually Apple did the sensible thing and just accepted we're kind of stuck with extensions.

Backwards compatibility is often at the root cause of "weird" decisions like this and is often not easy to engineer out without breaking things people rely upon.

I see a load of "pkf" files on my shared mp3 drive - they are created by the mac

Filing system structure

Comments