in most standard unix implementations, setting the value of errno is done
in userland by a thin layer of code in the standard c library that
interfaces between the c system calls and the actual kernel system calls.
are we expected to implement this, or to set errno from the kernel?
any ideas?
-gwa-
Word of warning:
Make sure that when setting up group permissions for your cvs repository,
you also give your partner execution access to any directories within
which your $CVSROOT directory is contained... otherwise, they'll get
permission denied errors when attempting to access the $CVSROOT directory
(in other words, if your CVSROOT is ~/cs161/cvsroot, make sure to also
give your partner execution permission on ~ and ~/cs161).
-Steve
One could write the file name, date and time of closure after the EOF
for the purpose of testing integrity of the file. If the file names do not
match, somehow an "outside" program probably manipulated the
file. A substantual difference between the directory entry date and
time and the EOF date and time may be useful in establishing when
something might have gone wrong. Also reading and writing beyond
the EOF might be valuable if one is testing the media's functionallity.
Also a decryption key might be recorded there because many would not
think to look or would believe the data there is garbage. Knowing
when a problem cropped up can be very useful in determining what the
problem is.
dave scrima
To:
cs161-list(a)fas.harvard.edu
Subject:
cs161-list digest, Vol 1 #14 - 2 msgs
From:
cs161-list-request(a)fas.harvard.edu Add to Contacts
Date:
Wed, Feb 28 2001 12:01:15 PM -0500 (EST)
Send cs161-list mailing list submissions to
cs161-list(a)fas.harvard.edu
To subscribe or unsubscribe via the World Wide Web, visit
http://www.fas.harvard.edu/mailman/listinfo/cs161-list
or, via email, send a message with subject or body 'help' to
cs161-list-request(a)fas.harvard.edu
You can reach the person managing the list at
cs161-list-admin(a)fas.harvard.edu
When replying, please edit your Subject line so it is more specific
than "Re: Contents of cs161-list digest..."
Today's Topics:
1. file seeks (Nicholas C. Murphy)
2. Re: file seeks (mike vernal)
--__--__--
Message: 1
From: "Nicholas C. Murphy" <nmurphy(a)fas.harvard.edu>
To: "Cs161-List@Fas. Harvard. Edu" <cs161-list(a)fas.harvard.edu>
Date: Wed, 28 Feb 2001 02:07:30 -0500
Subject: [cs161-list] file seeks
Reply-To: cs161-list(a)fas.harvard.edu
Under what circumstances would one want to seek beyond the end of a file?
Nick
--__--__--
Message: 2
Date: Wed, 28 Feb 2001 02:26:38 -0500 (EST)
From: mike vernal <vernal(a)fas.harvard.edu>
To: "Cs161-List@Fas. Harvard. Edu" <cs161-list(a)fas.harvard.edu>
Subject: Re: [cs161-list] file seeks
Reply-To: cs161-list(a)fas.harvard.edu
On Wed, 28 Feb 2001, Nicholas C. Murphy wrote:
> Under what circumstances would one want to seek beyond the end of a file?
I think one might want to do this so that they can then write beyond the
current EOF. It's conceivable that one would want to write structs A, B,
and C such that they are contiguous on disk, but that you wish to write
them in the chronological order of A, C, then B. I think you would seek
beyond the EOF to write C, possibly, then write B.
I think that, in general, the hole created by the seek-beyond-EOF is
filled in with 0s until it is written for real. Thus, if you
seeked-beyond the EOF, wrote, and then read some part of the hole, it
should return all 0.
well. this doesn't help too much. but maybe it does a little bit. I
can't think of too many concrete reasons as to why you would want to do
this, except if you had a funky file format where you wanted to write the
file footer before the file was finished writing.
-mike
--__--__--
_______________________________________________
cs161-list mailing list
cs161-list(a)fas.harvard.edu
http://www.fas.harvard.edu/mailman/listinfo/cs161-list
End of cs161-list Digest
Sent by Law Mail
