dhesi@bsu-cs.bsu.edu (Rahul Dhesi) (05/21/89)
While we are on the subject (sort of), here is another idea.
I want to be able to say
lseek (fd, (long) -count, 1);
write (fd, buf, count);
and have it work even if the file pointer is at the beginning of the
file. This will not be easy to implement. It will require the
filesystem to add a block to the beginning of the file (easy), and
remember where within that block the file actually starts (harder).
But it could be very useful. Many programs (e.g. sendmail) spend a lot
of time manipulating headers in a message without touching the body.
My repl command adds a Replied: header as the first line in each
message to which I reply. Currently these manipulations involve making
a new copy of the message.
--
Rahul Dhesi <dhesi@bsu-cs.bsu.edu>
UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesiugkamins@sunybcs.uucp (John Kaminski) (05/24/89)
In article <7344@bsu-cs.bsu.edu> dhesi@bsu-cs.bsu.edu (Rahul Dhesi) writes:
=>While we are on the subject (sort of), here is another idea.
=>
=>I want to be able to say
=>
=> lseek (fd, (long) -count, 1);
=> write (fd, buf, count);
=>
=>and have it work even if the file pointer is at the beginning of the
=>file. This will not be easy to implement. It will require the
=>filesystem to add a block to the beginning of the file (easy), and
=>remember where within that block the file actually starts (harder).
=>
=>But it could be very useful. Many programs (e.g. sendmail) spend a lot
=>of time manipulating headers in a message without touching the body.
=>My repl command adds a Replied: header as the first line in each
=>message to which I reply. Currently these manipulations involve making
=>a new copy of the message.
=>--
=>Rahul Dhesi <dhesi@bsu-cs.bsu.edu>
=>UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesi
why so difficult? If you are going to re-implement the filesystem (which
is what I surmise from your post), why not just add another field to the
inode that denotes the beginning offset within the first data block? Yet
another suggestion: put this offset in the data/disk blocks (This could
also be used for situations like "We just wiped
out the first three data blocks in this set of disk pointers. I guess we
could just set the 'valid data' field three disk pointers forward.").
Also, in the process, I think it would be good practice to put block types
into the blocks (is the block I'm reading supposed to be a data block, a
single indirect block, double indirect block, triple indirect block, or
unknown (error condition)?) It would be a consistency check for the
filesystem.
Maybe another neat thing to implement is the ability to splice into a file,
with several directory entries starting out at different places in the file.
kinda like an extended concept of the link and/or the symbolic link