Re: [C] Working with disk files. *long post warning*

From: Richard Heathfield (dontmail_at_address.co.uk.invalid)
Date: 03/02/04 

Date: Tue, 2 Mar 2004 06:39:05 +0000 (UTC)

Buck Rogers wrote:

> Hi guys! How are you? That's good.
>
> I am writing a program(my first ever!) which saves and reads
> data from a disk file.
> Firstly, here are some relevant code. I know you'd like code
> that you can compile, but there is alot of code, and I am not
> sure if all of it is necessary. Please let me know if you need
> more code.

Please always remember that, if you knew where the problem was, you would
have fixed it by now. :-)

I had a look at the code you posted and could find nothing that would
actually cause your problem. But I couldn't compile the code, so it was
impossible to investigate further. (Note: even if you'd supplied the whole
thing so that it compiled, the presence of calls such as clrscr() will
cause a link failure on my system.)

<snip>

> ============================================
> DISCLAIMER: I know using (feof) and scanf is bad, according to the FAQ,

Neither is bad if used correctly. You appeared, on a brief inspection, to be
using feof correctly, but scanf a little less so. (Don't ask me how to use
scanf, though.)

> but I have my reasons for using it. I also know using tabs are bad,
> because C has
> it's own width implementation.

No, tabs are fine too. Just don't post tabs IN USENET ARTICLES. :-) It's
okay to printf("\tThat was a tab, that was\n") if you want to. But whether
tabs are appropriate depends on your own program's needs.

> Some of you here have already previously dissected
> some of the code already, so please don't focuss too
> intently on it. :)

Yeah, I can see from what you posted that you've learned a few lessons
already. That's precisely why I wanted to help you out here; it's a shame
that I couldn't.

> 1. I've saved several "record" structures to a disk file using
> CreateNewAccount().
> The function DisplayAccounts(which also prints an index of each item
> displayed)
> has no problems displaying *all* structures in the disk file. But when I
> use
> OpenAccount to display a structure(selected by the user) using fseek(),
> the ouput
> is garbage. Can someone please explain why?

No. I may have missed something obvious, I suppose, but the code looks okay
to me, which means the problem probably lies elsewhere (although of course
the possibility exists that I missed something obvious).

> 3. In this instance, because I've saved only "record" structures
> so far, I can use fseek(), because I can use "sizeof" to hunt for
> the required structure.

Yes, you have fixed-size records, which does make searching a fair bit
simpler.

> What if I have a large disk file full of structures, arrays,
> strings, ints and everything else, all saved in non-contigous
> order?

Yes, that's when it gets to be fun.

> If the user chooses to display any of the items, I
> think fseek() will not work(efficiently). How can this
> be done?

Indexes, and so on.

> Even if I had some sort of index for *every* item that
> the user saved to the file, it is not immediately
> obvious to me how I can access the items, based on it's
> index. Any comments?

Just one: there's plenty of time to worry about databases when you've got
file-handling down pat. :-)

All right, all right. You can do this by writing your own big, scary C
functions to keep track of all the data, writing your own B+-tree
implementation, your own query language, etc... or you can do it by using
somebody /else's/ SQL library instead.

> 3. Are files saved in binary files "encrypted"? I've tried
> viewing binary files and all I see is garbage.

Write yourself a hex-dump program. Then dump a text file. What you'll see is
"ungarbage", which is just as unreadable as binary file garbage.

> Therefore, if I was to save sensitive information in binary mode,
> can I reasonably expect it to be "unviewable" by anyone else?

Consider the integer 1234. You can write this to a text file using fprintf:

fprintf(txtfp, "1234\n");

On an ASCII system, this would result in the following byte values being
written to the file:

49 4A 4B 4C 0D 0A

Now consider the integer 1234 again, this time written using fwrite:

i = 1234;
fwrite(&i, sizeof i, 1, binfp);

On a little-Endian ASCII 32-bit system such as the one you probably have,
this will result in the following bytes being written to the file:

D2 04 00 00

(if I got that right).

This appears to be "encrypted" until you realise that 4 * 256 is 1024, and
D2 is 13 * 16 + 2, which is 210. And 1024 + 210 is 1234.

> Or should I password protect the file(I have no idea
> how to do this!)?

Data encryption is a skill in its own right. If you thought C was hard, you
wait until you have a go at writing an encryption routine! Bottom line: if
you have any sense, you'll use a publicly-available encryption routine such
as GPG.

> 4. What happens if a text file is opened for appending in binary mode?

Most systems don't distinguish between text files and binary files; they're
just "files". If you open a file for appending in binary mode, stuff you
write to that file goes on the end, and no line conversions are done.

Whether the file remains readable by a text editor afterwards depends on
what data you write!

> What if a binary file is opened for appending in text mode("a+")?
> How is the data affected, if at all?

See above.

> Will I need a routine to check for return status of such operations?

You should always check the return status of any operation that (a) can go
wrong and (b) you can do something about if it /does/ go wrong. In other
words, few people bother checking a return value from printf. On the other
hand, *everybody* checks the return value of fopen -- don't they? 

-- 
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

Relevant Pages