Hacker News Reader

Your example would fail to accommodate the most basic application of files: logging and reading file logs at the same time.

Who says logs have to be written to a file — at least as far as the user is concerned? Logs are a series of events — a LogStore will let you read events as they are appended. And even if you do want to store logs in “files”, the solution proposed here here let’s you borrow them for the owning application.

My question goes more like this: “why the hell do you want to re-approach the idea of a filesystem if the new approach can’t even accommodate something as simple as storing log files?”.

It may be time for something completely different. Just stop calling it a filesystem.

Again, why do you care about files? Logs have nothing to do with files. Files are just the interface used by filesystem to show the event stream that is logs so you can use file based tools to access the.

I am not calling it a filesystem. Let’s call it a data bank?

It already exists in the form of databases.

First that comes to mind is etcd.

Where do you plan to store the logs then?

On the disk, as usual. Files are, after all, an interface.

That's handled by point 6. You would be able to have shared ownership of the log files, but you wouldn't be able to just write to it willy-nilly. In this case, the specialized application would be trivial because it would just need to ensure that writes are append-only.

> Applications can provide the ability for shared ownership, but those would by specialized applications capable of handling and merging simultaneous changes.

Agreed.

Surely my logging application would "own" the read-write handle, while my tail application merely "borrowed" a handle for read-only.

How do those semantics differ from multi-writers which can all write in transactional blocks?

2 just sounds like reinventing the file system, now with more bugs.

No, it is not reinventing the filesystem -- it's more like a file-vault or a file-bank. Anyone looking to operate on the files must either borrow (to read) or take ownership of (to write). The difference is that while a filesystem unlimited access to all files, the app in question is meant to be more sandboxed -- handling only the files it is asked to -- e.g. shared documents that can be edited by multiple apps. Each user (on a multi-user system) will have their file-vault/file-bank and files must be explicitly transferred for shared access.

Finally, as I said, it is a straw-man proposal -- I haven't spent time working out all the kinks.

> No, it is not reinventing the filesystem -- it's more like a file-vault or a file-bank. Anyone looking to operate on the files must either borrow (to read) or take ownership of (to write).

So flock() and file permissions then?

There are improvements that could be made here -- app-level permissions in addition to user-level permissions for example. But it's still fundamentally a filesystem.

All of this can be implemented on top of a file system, of course. What do you think iPadOS does?

We are talking about what the user/application sees and is capable of accessing.

> We are talking about what the user/application sees and is capable of accessing.

But how is that different than a filesystem?

Suppose we add application-based ACLs to file permissions. Then the app does open("/path/to/file", O_RDONLY) as ever. If the app has permission to the file, it gets the new fd. If it doesn't, it gets EACCES as usual. Or the OS displays a dialog asking whether the app should have permanent or one-time access to that file, and then the call doesn't return until the user chooses one.

I don't see a fundamental change here. The application wouldn't necessarily even have to be modified.

By that logic, there is nothing wrong with having a flat memory address space. With access control, the OS can ensure that one application never access another’s memory area. Why do we need isolated virtual address spaces so that application always believes it is the only application running?

> Why do we need isolated virtual address spaces so that application always believes it is the only application running?

Historically mostly because of swap, so the OS can move a page from memory to disk and then back to a different physical memory location without modifying the application's pointers. On large systems with 32-bit applications it was advantageous because the system may have had more memory than 32-bit pointers can address and then each application can have its own address space. ASLR nowadays.

But filesystems already have the equivalent abstraction. If you run out of space on /dev/sda you can add /dev/sdb, copy /home to it and then mount /dev/sdb1 /home and the application that reads /home/alice/file is blissfully unaware that anything has changed. Heck, half the time you're not even reading from the physical drive, the data is cached in memory and you're really reading it out of the page cache.

That's interesting. Some time ago I had a similar idea, but with the following differences:

3. Ownership cannot be transferred. A file remains in the same application throughout its lifecycle.

4. An application can give another application read-only access to a namespace containing one or more files.

6. An application can give another application read/write access to a namespace containing one or more files through a transaction mechanism.

Do you see any advantages or disadvantages of both approaches from your point of view?

The idea behind ownership transfer is to ensure that an application never sees another application’s namespace. Ownership transfer doesn’t really involve copying files as it does on iPadOS — it is still held at the same location on disk. The original application can just no longer see it as it no longer remains in its namespace. At the end of the operation, the second application may choose to retain or relinquish the file as needed.

I have photos on my computer, even though I don't use a photo management application. I have compressed files. I have files taken from other machines. I remove applications. I create my own file formats. Applications themselves are files.

Who owns all the unassigned stuff? The file system. Give it a different name and you change nothing.

You don't use a photo management application because the file-system exposes photos as files. It is like saying -- in java parlance -- I am perfectly fine using object for everything -- I don't need any other data type. In the hypothetical system I proposed, the photo store would be exposed via an application like Explorer/Finder -- just tailored for viewing photos.

Compressed files are containers for files -- they are nothing on their own.

> Applications themselves are files.

Sure -- they go into ApplicationStore -- which tailored for say, quick application discovery and launch.

> Who owns all the unassigned stuff? T

What exactly is the unassigned stuff? Files taken from other machines? I don't see why they can't be put into an appropriate store based on type.

> I create my own file formats.

I assume you create your own file formats because you develop your own applications? In that case, your application will be the owner of the file in question.

What if I don't desire a gui application store or desire a different one or switch application stores or move a dir with executable files from one machine to another?

Is the application store the only way to start at app? If I bind a global hotkey to start an app how is that handled?

How about I have an addon for firefox that allows me to bind keys to operations which can include javascript which can itself start applications which can then write to files.

I use this for example to open links in mpv with a singular line in my config file for the addon, tridactyl,

bind V hint -W ! mpv this means show a hint on links and for the given link send the chosen link to mpv, wherein mpv will look at the link and if it can read it will use youtube-dl to download the link to a temp dir and display the video.

Who owns what there?

Do I have to access my photos via a a singular photo manager? I can imagine images accessed in 17 different contexts by 30 different apps does each of them need permission to access each dir which contains images or just generically to access images.

Does this mean that a singular permission would control both access to the browsers cached image of the ycombinator logo on this page and some ones nude selfies?

I just don't think you can cleanly map apps -> files beyond the trivial cases without making something inflexible that sucks to use.

> What if I don't desire a gui application store or desire a different one or switch application stores or move a dir with executable files from one machine to another?

What does any of this have to do with a GUI? And for transporting, extract the data into a portable bundle, or take the entire store.

> Is the application store the only way to start at app? If I bind a global hotkey to start an app how is that handled?

Again, what does any of this have to do with how the applications are stored? Can you see the files that make up an iOS app? You can still start them, can’t you? A macOS app is a folder called Something.app, the actual binary lies somewhere inside. Do you typically need to poke inside the .app folder?

> How about I have an addon for firefox that allows me to bind keys to operations which can include javascript which can itself start applications which can then write to files.

As far as the computer is concerned, you are merely starting a process. Again, what does that have to do with how applications are stored. They can be triggered however and wherever they are stored.

> Do I have to access my photos via a a singular photo manager? I can imagine images accessed in 17 different contexts by 30 different apps does each of them need permission to access each dir which contains images or just generically to access images

This is already being handled on iOS and Android. Photos apps is merely the default interface for the PhotoStore. You can access your photos from any app.

> Does this mean that a singular permission would control both access to the browsers cached image of the ycombinator logo on this page and some ones nude selfies?

Namespaces inside individual stores, or separate stores.

1. At present I can take a text file even not on the PATH put a shebang on it, mark it executable, and execute it because the underlying medium is a user visible hierarchical data store that I interact with directly. It's not clear how the app store application would be associated with it or even know about it or how say a terminal would borrow the application that it didn't know about to run it.

2. An actual filesystem allows you to run things that aren't in an app store bundle

3. Which app owns the files when An app starts an addon which starts a process which runs an app which accesses a file. Does the last app in the chain own the file? This is challenging because plenty of apps could do things based on arguments passed in that involve modifying the filesystem.

4. The way ios and android handle 2 apps accessing the same file is only acceptable if someone has envisioned the way you want this to happen to some degree on both ends. A file picker works on any type of file and an OS that can't have a file picker seems to be objectively worse whereas adding an image picker would be an upgrade. I enjoy using calibre to manage how ebooks are stored and beets for music but neither is bounded by an underlying system designed by others and neither locks said files into said structure or limits access according to it. Its trivial to all out to calibre including via the cli get the full path to a book for example and do something with it.

It seems fairly clear to me that there several layers of filesystem access.

Applications that should never have access to your filesystem because they are malicious. Avoided by installing only from trusted sources to avoid malware in the first place the best possible line of defense. This also makes it possible to get a list of applications that ought to be revoked and communicate this to users.

Running code that should have no or very very controlled access to the filesystem ordinarilylike the Javascript on this page.

Apps that run as the user on their behalf that accesses the filesystem.

You appear to want to pile a layer on top of the last. This appears to only work for the simpler cases and I'm not even clear what the benefits are supposed to be.

> It's not clear how the app store application would be associated with it or even know about it or how say a terminal would borrow the application that it didn't know about to run it.

Where does the file come from? Suppose you create a file in your terminal application, then it lives inside the terminal and you can use your terminal to run it.

> 2. An actual filesystem allows you to run things that aren't in an app store bundle

Neither a global namespace (file system) nor an appstore are required to execute a program.

> Which app owns the files when An app starts an addon which starts a process which runs an app which accesses a file.

This should be at the discretion of the application developer. This is also the way browsers already work with sandboxed addons.

> This appears to only work for the simpler cases and I'm not even clear what the benefits are supposed to be.

If you don't put everything in the same global namespace, you get more security, cohesion and compatibility. That's why we use VMs, containers, sandboxes, and various user accounts instead of doing everything in a single filesystem using the root user.

I think constraining many apps access to the file system is a fine idea. I just think think that mapping files to applications very quickly becomes farcical as the abstraction just clearly doesn't match.

It not even optimally secure. Why for example would your image editor need access to all your image files instead of just the ones passed in via a secure system dialog?

In that instance the dialog would be the checkpoint not the some weird file system borrow checker.

Sounds like rust’s borrow checker but for files.

That is where I got the idea. :-)

Instead of "ownership transfer" you can also use locks. Read and write locks are already supported on many filesystems.

Well, you can also use global variables safely with locks.

How much is that different from how it works on iPadOS?

It is meant to be more powerful and flexible than what iPad OS does, but somewhat similar.

basically the windows document folder

Except, you won’t see files, just photos, movies, documents, etc.