Re: albods

Alexander_Maryanchick%STORACTIVE@storactive.com
Wed, 7 Jul 1999 16:03:07 +0400


> His idea is to used a modified loop driver, and build a filesystem in
> a regular file, then mount this FS if you want to access different
> data "streams".

This is exactly the OLE structured storage. :-(
With all its bugs (holes, fragmentation, etc.)

I think you mean loop *interface* - without real loop FS.
I.e. mount(forked_file); instead of open(forked_directory);
where forked_file (S_ISFORKED) is stored (physically) as regular directory.
In this case holes are absent.
But this is equal to a new open() flag - O_MOUNT.
/* Sounds simple, isn't it? ;-) */

IMHO, this is a 15-minutes work for reiserfs.
For compatibility with other FS may be used a new libefs option.
All other cool FS features may be easily added later.

The solution is nearby !!!

Solved problems:
- None of old applications can break albods.
- New applications can use albods with 100% efficiency.
- Old applications can get access to the albods via avfs/podfuk name
convention.
- No limitations: we get a real FS tree (with all access modes, links,
etc.)

But there are still some unsolved problems :-(.
If somebody find a solution - then the albods problem is solved.
- Security hole:
~/letter/@albod/ACL is rw-r-----
~/letter is rw-rw-rw- => ACL is rw-rw-rw- too :-(.
/* A raw idea: O_MOUNT may be used only for rw*--*--* files. */
- Broken file extensions
(What #%$ moved this crap to UNIX?.. But I know why he did it: he had no
albods :-P)
if forked.mp3 has MP3 header - it may crash a dumb player.
if forked.mp3 has no MP3 header - it will refuse MIME types.
/* an old player must access forked.mp3 only via forked.mp3@albod/data
*/
/* A raw idea: rewrite GNOME & KDE. */
- Broken scripts.
grep /forked_files/forked@albod/data will work.
but grep /forked_files/* - will fail.
/* A raw idea: rewrite findutils, etc. */

Any ideas?

Best regards

Alexander

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/