Ideas for changes to Unix filesystem

Root Boy Jim rbj at uunet.UU.NET
Wed Feb 6 16:06:30 AEST 1991


In article <1991Jan30.143326.16676 at socs.uts.edu.au> jeremy at 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 <rbj at uunet.uu.net>
	I got a head full of ideas
	They're driving me insane



More information about the Comp.unix.internals mailing list