Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!rbj From: rbj@uunet.UU.NET (Root Boy Jim) Newsgroups: comp.unix.internals Subject: Re: Ideas for changes to Unix filesystem Message-ID: <121494@uunet.UU.NET> Date: 6 Feb 91 05:06:30 GMT References: <1991Jan30.143326.16676@socs.uts.edu.au> Organization: UUNET Communications Services, Falls Church, VA Lines: 41 In article <1991Jan30.143326.16676@socs.uts.edu.au> jeremy@socs.uts.edu.au (Jeremy Fitzhardinge) writes: >I have 3 main ideas for change: > >1 - a flink(char *path, int fd) system call/operation. Many people have complained about "security problems". I don't see any. If you have an fd, you have the data, so you can copy it to your own file anyway. An flink is just faster. >2 - insertion/deletion in the middle of a file without copying I don't like this any better than anyone else, with one exception. I can see extending f?truncate to trim the beginning. The kernel would keep an beginning pointer for it's own internal use. Well, the implementation gets a bit tricky, but it could work. >3 - limited sized files Hey, pipes already do this! They treat the ten direct block pointers as a ring buffer. Now the question becomes, what sizes will be supported, and how do you know where to start scanning when the ring wraps. Almost certainly you will be in the middle of a "record" if using variable ones. Cron jobs to trim log files can lose log entrys. You have to rename the file, then send a signal to any process that keeps the file open so it can open the new log. Or lock the file before renaming it. All of these have been discussed before. I think the consensus is that each has its appeal, for about five minutes. However, ideas stimulate us to look for better ways of doing things. For example, instead of using a log file, a unix domain socket could be written to. It could write flat files, circular files, filter entrys, update a database, send to a secure machine, whatever. -- Root Boy Jim Cottrell I got a head full of ideas They're driving me insane