4 ms·
I don't really understand what you mean, for me what you're saying is a contradiction: >We have VERY long history using file system, it is the base of every OS
by simias 9y ago
I don't really understand what you mean, for me what you're saying is a contradiction:
>We have VERY long history using file system, it is the base of every OS, it has solid API, every language provide similar access interface, everybody familiar with how to talk with file system.
I agree, but then you don't really do that, do you? Merely mimicking the Rust fs API is not enough to call your project a "filesystem" in my opinion. It's actually probably the least of my concerns when it comes to using a filesystem.
On the other hand not being able to use the familiar "cd", "grep", "cp", "mv" and "cat" the contents of this so-called filesystem means that it's really not that familiar at all.
I'm not sure I see the point of the "minimal attack surface", you can create private fuse mounts that can't be accessed by other UIDs. And if you're worried about same-UID compromised programs snooping around then it's game over anyway. That smells a bit like FUD to me.
- burmecia 9y agoIMO, "cd", "grep", "cp" and etc. are provided by shell and os, not by file system. They are just human interface to help you interact with the underlying file system. Can you call "cd" on an ext4 file system directly? No. The shell will invoke "cd" or similar process and that process will do the system call to kernel, and then kernel will call the ext4 kernel module through VFS. https://www.kernel.org/doc/Documentation/filesystems/vfs.txt https://www.kernel.org/doc/Documentation/filesystems/vfs.txt For Zbox, it is just like a kernel module but runs inside application memory space. To interact with it, you have to use a set of 'standard' API, in kernel that is VFS, in Zbox that is Rust's fs API (not exact same, but similar).
- simias 9y agoDo you often interact with an ext4 file system using the Linux VFS? I'm not sure it helps your "familiarity" argument. It's not just about familiarity either, it's also interoperability. Tons of 3rd party applications know how to interact with real filesystems using the standard POSIX "open", "stat", "unlink" etc... You can make incremental backups using rsync, you can use a choice of many browsers to explore its contents, you can use logrotate, you can use tail -f to monitor data appended to a file etc... IMO if you can't do this you don't have a filesystem, you have a database with filesystem semantics. Anyway, by now anybody reading this discussion will have made up their mind so let's leave it at that. And good luck with your project nonetheless, semantics aside it's rather impressive.