Re: Programming in standard c
- From: gordonb.dan50@xxxxxxxxxxx (Gordon Burditt)
- Date: Mon, 07 Jan 2008 02:48:53 -0000
So which is the correct size of a partially compressed sparse file? The
The file size being discussed was *the size of the file when it is
read into memory* (and you have to specify text or binary mode).
If you can actually specify the mode, in many cases the size will be
different. Is the OS supposed to keep track of both and report back the
one you want? If we're defining a standard C routine to determine file
size, do we pass a parameter specifying which mode to use?
Yes, you'd have to pass a parameter specifying which mode to use,
or open the file and let the system use the same mode as what you
opened it with. Or have two different functions, like filetextsize()
and filebinarysize(). On POSIX and Windows, stat() could be used
to provide filebinarysize(). On POSIX, filetextsize() is the same
as filebinarysize(). And in any case, you can obtain the required
value by opening the file in the appropriate mode, calling fgetc()
repeatedly, and counting the number of calls. I didn't say it would
be fast.
This is not the only "file size" definition, but it's the one relevant
to reading the whole file into memory.
It's at least two distinct sizes already.
Which file mode is relevant to the file you intend reading into
memory? If you pass it an open FILE * handle, it should already
know what mode you are interested in (if it makes a difference).
If you pass it a file name, you'll need a mode also.
The number of bytes when you read it in. This can change with time. To
accurately measure it, you open, read, and close it without any
intervening accesses by another program. Some systems let you PREVENT
such accesses with mandatory file locking.
Sure, and some don't, and in the context of C, you can't rely on such
measures existing, and even if they do, we're still talking a minimum of
two different sizes.
So do tell, which is the "correct" size.
For this problem, the size of the file when you read it into memory is
the size of the file when you read it into memory in a particular mode
(text or binary) and at a particular time.
So two distinct sizes, then. Again - which is the correct one? Which
If you are intending to read the file into memory, which mode to you
intend to use when reading it? That is the correct mode to use for
computing the size.
will our file size function return? Should it have a parameter which lets
you specify? Is the size you determine _now_ the size of the file at the
time you read it? Several examples have been given where this won't be
the case.
The function returns a value as of a particular time. What gets
nasty is when the function's accesses to the file are interleaved
with accesses by other program or programs unknown.
To get a consistent value,
you need to do all your accesses in one sequence with no intervening
accesses from other programs.
Sounds good - can you explain how to ensure this in standard C code? If
An *implementation* of a proposed function to add to standard C can
use non-standard hooks which standard C code can't (like file locking).
you can't, then whether you can determine the file size or not sorta
becomes irrelevant, as it may well change at the drop of a hat.
You're right. Files can change size, and trying to get the file
size ahead of time, no matter how you define it, is a problem. You
also see the same problem when people ask "how can I find out if/how
many other programs have the file open?". That won't work either:
unless you can get the function to return an accurate value *AND
PREVENT IT FROM CHANGING* until the caller of the function lets go.
That tends to be a significant opening for a denial-of-service
attack by a buggy or malicious caller of the file size function.
There are other uses of the file size, such as comparing the output
size with the expected output size in a regression test. (Next step,
if the file sizes match, is to compare them).
.
- Follow-Ups:
- Re: Programming in standard c
- From: Kelsey Bjarnason
- Re: Programming in standard c
- References:
- Re: Programming in standard c
- From: Kelsey Bjarnason
- Re: Programming in standard c
- From: Gordon Burditt
- Re: Programming in standard c
- From: Kelsey Bjarnason
- Re: Programming in standard c
- Prev by Date: Re: small string question
- Next by Date: Re: some strange for me (addition)
- Previous by thread: Re: Programming in standard c
- Next by thread: Re: Programming in standard c
- Index(es):
Relevant Pages
|
