In a recent project that I had at school I was supposed to update
database. This was my algorithm.

1. Open file in read only.
2. Load the datafile to a linked list (To keep sorted).

3. Get info from user.
  3.1  Add the info to list and loop to gather more data if instructed.

4. Close the file.
5. Open the same file in write only mode (To write the sorted list and
                                          replace the old one ).
6. Write the linked list to the file.
7. Close the file

At this time I did not know about the function remove(). My question is:

   Is my approach of updating the file using opening the file in two
   different modes OK? I was never to sure and there was not feedback from
   the instructor when he gave me back the assignment. I am sure you are
   probably wondering just like I wonder then and continue to wonder
   in almost every assignment what is the point. I suppose nothing other
   than the grade???

   Would it be better to open the file once and use remove() somewhere  
   in the middle?

   Does it matter at all which approach I use?

   I am aware that it would be better to write immediately to the file
   using fseek and related functions. I am assuming it would be safer
   since it would not be cool to have a power loss after entering 100
   records which were kept in memory.  Also, performance is not an issue
   since I have to wait for the  new input from the user anyway. I feel
   very confident about this and any suggestions that indicate otherwise
   will be appreciated.

   The exercise however, was specific as to which functions to use and
   the professor specifically asked me not to use the set of functions
   that manipulate the file directly. remove() was not included. I am
   reading another text which talks about tmpnam(), remove(), and rename()
   and I am curious about this approach.

  ))\\\\\|/////((
   )\\\\\|/////(
    \\  ^ ^  //

   oOOo () oOoo

  Alvaro R. Zuniga
           Oooo
    oooO   (   )  
   (   )    ) /
    \ {    (_/  
     \_)
This has to bee the coolest newsgroup I have ever seen. I hope I do not
become a rotten apple. I am sure you will not let me.
--

Personally I would much prefer to see you write another file rather than
overwrite the original.  Consider what happens if your machine crashes
during the process of writing.

Check out the rename function.

Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
--

Personally I would much prefer to see you write another file rather than
overwrite the original.  Consider what happens if your machine crashes
during the process of writing.

Check out the rename function.

Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
--

[snip]
[snip]

I find for portability fopen("filename", "w") works better than remove(),
also if you happen to want to delete a file that may be a symbloic link
without removing the link itself then fopen("filename", "w") followed by
fclose() does the trick wonderfully.

[snip]

Not that I know.
--

[ ... ]

I can't think of any reason it would be more portable -- both fopen
and remove are required for a conforming implementation of C.

However, they do NOT do the same thing at all.

Here you've got things exactly backwards.  If you use fopen to
truncate the file, then the file itself is truncated, and ALL links
(whether hard or symbolic) will show the file as being truncated.  
Worse yet, the link you started with will still exist, and will simply
refer to a file of zero length.

OTOH, if you use remove, it'll normally equate to (for example) unlink
on a UNIX system, so when you remove a link to the file, it only
affects that link, and all other links will see the file unchanged.

If you deal with a system where there's a 1:1 correspondence between
file names and files themselves (e.g. MS-DOS) you could argue that the
two are fairly similar.  When you get to a system that supports
multiple links to a file (e.g. Windows NT or UNIX) that argument
becomes _completely_ specious and nonsensical.  The two are doing
entirely different sorts of things.

I'm reasonably certain there's no such thing as a system that has
remove() remove the entire file regardless of how many links there
might be to it -- if nothing else, this would simply be a difficult,
time-consuming thing to do.  As-is, you know where the link is, and
you remove that.  You decrement the reference count in the file's own
entry (e.g. inode under UNIX) and if it's zero, you can remove the
file itself.  However, to remove ALL links to the file, you'd
basically have to search the entire disk for links to the same file,
and remove all of them until the ref-count went to zero.  At least in
the file systems of which I'm aware, there's no link from the file
entry itself back to each of the links, so there's no quick or
convenient method of finding all links to a file to remove them all.
--

I should have explained that better. Read delete as empty. I had problems
usinging remove() in one of my programs as (unknown to the program) people
had been setting symlinks, so I taught the program to deal with empty
files and just do the fopen(filename, "w"); fclose(); trick instead of
using remove().
--