🚀 go-pugleaf

In <40u1ua$m0l@oddball.sjc.MENTORG.COM>, ewill@hpewill.sje.mentorg.com (Eric Williams @ PCB x5577) writes:
>In article <40l9d9$8i1@news.ios.com>, nnb@haven.ios.com (Nikolai Bezroukov) writes:
>|> doug blakey (dblakey@hookup.net) wrote:
>|> : Here's my idea of an "Dream OS" I'd love some feedback as to how plausible
>|> : it is.
>|> ...
>|> 
>|> : 5. File sysem
>|> :    -Hierarchy (of course)
>|> :    -Multi-gigabyte support
>|> :    -Encryption
>|> :    -long file name support
>|> :    -Suggestions Please (I don't know much abour file systems)
>|> 
>|>   - Decent set of file attributes for multi-level storage is a must 
>|>     (last_acess, no_of_access, etc with user defines EA (with OS2-like))
>|>   - ZIP-files should be consided as psoudo-directories (with 
>|>     limitations) with native support for basic op (view, copy, move,
>|>      rename delete).  
>
>This would be very difficult without reading and uncompressing
>the entire ZIP file into memory before operating on it.

Why should this be difficult, Simply have the contents of the archive 
stored in extended attributes as well as internal to the archive, and have
the file system support archives stored this way as being treated as 
directories. There are enough utilities out there that will simply give 
you a list of the contents of an archive already that this should not be 
all that difficult. unzip -v does not decompress the archive to get a 
directory, it simply searches through the archive until it finds the 
directory listing stored inside. (you can also simply get out a file 
lister and move to the end of the archive and see how the archive is 
stored.) 

This works well with zip, arj, zoo and lha. binhex I don't know about, 
tar is a seprate issue, as is gzip. though with zcat you can do
functionally the same to tar files. simply gives you a listing of the 
files in the archive, created by scanning the archive and building the 
list on the fly.

>One could also request this for TAR files, ARJ files,
>ZOO files, CPIO files, HEXBIN files, AR files, and basically
>any sort of archiver that currently exists out there.
>
>I could see this sort of thing being done by a daemon that
>hooks up to the kernel much like rpc.nfsd does, which would
>make this far more general.  Hopefully such a daemon
>could be hooked up to a dynamically extensible RAM disk
>(something like the Amiga's, only with virtual memory
>capability).
>
>Of course, if we're going to go to all that trouble,
>perhaps we should just unzip it onto the disk
>in the first place. :-)

Why? simply store the information in EA's, and extend the FileSystem tools
to support directory listings in the EA's. You could then if you desire 
extend the file system tools to allow you to modify the contents of the
archive simply by modifying the EA's. I am not saying that this would be 
easy, for OS/2 at least, you need to creat some DLL extensions, add a 
feature into the archive tools, and extend the file-system utilities to 
support this. We all know that that is real difficult. I would be 
surprised if it were accomplished any time prior to 2100.

What? You say that most of this is already being done by programs like
FM/2, Object Desktop, and a host of other tools out there for OS/2? Mind 
if I say that I am not surprised, I was refering to 2100 Tuesday, January
1, 1980? Sorry to disapoint you.

-Rusty

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
The opinions expressed above have nothing to do with the opinions of my
employer, and depending up on the condigion I am in when I post them may
have nothing to do with opinions of the poster.

        #####
        #~ ~#
--ooOO^( + + )^OOoo----------------------------------
----------U------------------------------------------
 |    |    |    |    |    |    |    |    |    |    |
-----------------------------------------------------
    |    |    |    |    |    |    |    |    |    |
rusty@minn.net ---- jrcurry@reliant.mnet.uswest.com -