Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!world!bzs From: bzs@world.std.com (Barry Shein) Newsgroups: comp.unix.internals Subject: Re: Ideas for changes to Unix filesystem Message-ID: Date: 4 Feb 91 05:31:39 GMT References: <1991Jan30.143326.16676@socs.uts.edu.au> <414@appserv.Eng.Sun.COM> Sender: bzs@world.std.com (Barry Shein) Organization: The World Lines: 32 In-Reply-To: lm@slovax.Eng.Sun.COM's message of 4 Feb 91 03:54:50 GMT Actually, I'm going to take exception with all these old fuddy-duddies who seem to be defending the status quo and say that the idea of manipulating blocks within a file is perfectly rational and would be useful. I don't know why everyone seems to think it's a wild idea. Think of fixed length record files and inserting into them, it would be nice to be able to just copy/munge the block numbers rather than the data. You'd need operators for inserting and deleting, perhaps one function could do both (who cares, two functions, or one with flags, easy enough to use flags.) Moving blocks around (e.g. a sort) would be handy also. Of course, you could do most of this virtually (although really freeing space is a problem) by just writing an application library which goes through a block table. I suppose the obvious suggestion would be to try writing and putting such a library into common use and seeing if it gets used. Personally, I'd be more interested in a meta-file format where you can create files which point into other files, a file-type made up of an (offset, length) tuple list. The hard part is reference counts. But it is the file system equivalent of a database "view". I could think of many uses for that, and its operators (e.g. hypertext.) -- -Barry Shein Software Tool & Die | bzs@world.std.com | uunet!world!bzs Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD