[mr_toad]

> Considering many people doesn't know what a file is, keeping the spirit alive is important, I think.

Files aren’t sacred. It’s actually troubling that many technical people never consider alternatives. Most of the worlds data today is probably not stored in filesystems, rather in databases and object stores that use custom storage backends.

[bayindirh]

I didn't make such claim, and there's no need to comeback with such force. A file is a good abstraction of what a "casual" user works with. E-mails, documents, images, videos. These are great applications for files. Also, while some people hate UNIX's "everything is a file" approach with a passion, it's a great way to allow people to explore what's behind the wallpaper they see every day.

You know what, these big databases and object stores are living on bog standard but scalable filesystems most of the time. Ceph, ZFS, Lustre, etc., and sharded/stored as files. There are some very high performance and bespoke systems out there [0], yet they also provide POSIX compliant filesystem views outside, not because they are sacred, but because it works.

Filesystems provide great utilities for making abstractions other than files, by using files as universal containers you can play with. Again, while they are not sacred, they are an important building block, and they're here to stay. Creating a custom storage backend, throwing away all filesystem stuff is a fool's errand, since filesystems handle much more than providing a tree and some attributes on that file/folder hierarchy. Since they are the first level on top of physical storage devices, they also take care of the device underneath them (e.g. TRIM, FFFS (Flash Friendly File System), etc.).

It's a great irony that E-Mails are already stored as human readable databases on disks.

[0]: https://docs.weka.io/4.3/weka-system-overview/filesystems

[mr_toad]

I’m just pushing back on the notional ignorance of non-technical users for not understanding one abstraction among many.

And I’m complaining about technical and non-technical users who don’t understand why object stores (and web servers, and ftp servers, and archives) aren’t file systems just because they can hold files.

And don’t get me started on documents. Document object models can be so much more when they’re not just treated as a sequence of bytes.

[59percentmore]

After the nth time of my Android Chrome app silently corrupting and auto-deleting my browsing history (all of it; it's not a bug, it's the intended behavior!), would love to hear about a file alternative that's modular enough to resist that kind of catastrophic failure and interoperable enough to inspect/repair if anything ever happens.

[inigyou]

how would any alternative design prevent intended behavior?

But the most obvious alternative to a filesystem would be formatting a whole hard drive as an sqlite database. Obviously it would be a radical rethink in OS design.

There are also "single-level stores" from the last millennium - designs where there is no separation between volatile and nonvolatile storage. All memory in these systems is treated as nonvolatile. A Word document, for example, would be something like a suspended Word process. A directory is a process that only manages pointers to other files and directories. Obviously processes must be extremely lightweight in such a system. KeyKOS is an example of this and you can read papers about it and its Unix emulation layer. This is one of the many things humanity explored before settling on the hierarchical filesystem as the base layer of storage.

[59percentmore]

>how would any alternative design prevent intended behavior?

If you're asking how something other than the sqlite database Chrome profile data is stored in would prevent the intended behavior of deleting corrupted files silently, obviously the two issues are orthogonal. But a file-based system would mean a corrupted file (the others untouched) rather than a corrupted database (everything is gone). I'm horrified at the idea of replacing my resilient, inherently modular set of files with a brittle monolithic database.

[bayindirh]

> But the most obvious alternative to a filesystem would be formatting a whole hard drive as an sqlite database.

At the end of the day, you'll be chasing pointers inside that SQLite database, where you store tables, indexes and such. Interestingly, this is how a filesystem works. Tables, indexes, redirections and fields. Very much like a database. EXT4 is a table of redirections, nothing fancy [0].

[0]: https://blogs.oracle.com/linux/understanding-ext4-disk-layou...

[inigyou]

Yes, believe it or not, all memory gets populated with data structures to be useful. That doesn't mean all data structures are equivalent.

[Levitz]

I agree that files aren't sacred, they are just another abstraction at the end of the day, but what the other user (I think) is referring to is the trend in which, as smartphone use becomes ubiquitous, users lose sight of the technical side of things.

It's not that the average user is ignorant of the many ways in which data can be stored and retrieved. It's that they are becoming ignorant of such abstractions existing altogether. It's hard to start thinking about how images are stored if all the user knows is "they are in the gallery".