using fstream objects in a multiuser environ.

[Pablo]

At my current job I've been tasked with maintaining a very old C++
application written largely in ANSI c++ in what I believe to be with an old
DOS based Borland compiler. I'm trying to add a simple event logging
component to the application. Initially I began with a simple:

[...]
fstream dumpfile
dumpfile.open(fname,std::ios_base::out | std::ios_base::app);
[...]
//Event log occurs
dumpfile << dumptext << std::endl;
[...]

But I realized that I would (and did when I started testing) have a problem
because this DOS app is used in a multiuser environment. Competing users
will overwrite eachothers entries if they occur at the same time.
Previously, my pure ANSI c++ experience has been in primarily single
computer/user environs- and any multiuser experience usually got into OS
specific extentions so this never was an issue.

My question is, what methods would someone suggest to me to allow multiuser
access (using any object available in an ANSI environment) which would avoid
such multiuser issues as described above.

Having some experience with race conditions in other os/languages unrelated
to C++, I came up with one idea-- which seemed kludgey. That is to first
check to see if a 'locking' control file exists in a common directory. If
it sees a file there, assume someone else has control of the log file, wait,
repeat step one. If it doesn't find a locking file, create it and write
some unique set of bytes determined by the individual instance (user) of the
app. Wait a 'reasonable' time, then re-read the bytes-- if said bytes
remain as the unique identifier- I can conclude that I have control and can
then open the real log file, write, then delete the 'locking' file when the
write and buffer flush(close) on the log file are complete.

Again, that's the only thing I've come up with. Any advice/criticism (or
especially new ideas) would be appreciated. Thanks in advance,

Paul

[rajkumar]

1) Give each user his own error file with a name like
filename_processid_random_number.txt
2) If you want just one global error file for all users... you can make
sure each user app process logs temporally to memory. Periodically
they could open the global error file with exclusive access flush their
log and close the file

Raj

[Pablo]

<ra******@hotmail.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...

1) Give each user his own error file with a name like
filename_processid_random_number.txt
2) If you want just one global error file for all users... you can make
sure each user app process logs temporally to memory. Periodically
they could open the global error file with exclusive access flush their
log and close the file

1: Unfortunately I have a specific application need which disallows a
localized or 'many' log files situation. It must be a centralized log file.

2: But my understanding of ANSI c++ is that there is no exclusive open for a
file. Am I incorrect? Is there an ANSI specification for exclusive access
with an FSTREAM object? Or any other file stream object? I'll research
while I wait for a reply.

Paul

[Duane Hebert]

"Pablo" <jn**********@comcast.net> wrote in message news:K8********************@comcast.com...

Having some experience with race conditions in other os/languages unrelated
to C++, I came up with one idea-- which seemed kludgey. That is to first
check to see if a 'locking' control file exists in a common directory. If
it sees a file there, assume someone else has control of the log file, wait,
repeat step one. If it doesn't find a locking file, create it and write
some unique set of bytes determined by the individual instance (user) of the
app. Wait a 'reasonable' time, then re-read the bytes-- if said bytes
remain as the unique identifier- I can conclude that I have control and can
then open the real log file, write, then delete the 'locking' file when the
write and buffer flush(close) on the log file are complete.

Again, that's the only thing I've come up with. Any advice/criticism (or
especially new ideas) would be appreciated. Thanks in advance,

The problem with the lock file is that if one of the users crashes
or has some problems (nic disconnect etc.) the file may not
get cleaned up and you'll be stuck. You probably need some
sort of static instance, maybe a singleton with mutex locks
and a queue mechanism to guarantee that all users work.

Another alternative may be to log to a separate file for
each user and periodically do some sort of merge
into one common file. At least at that point you could
open the files as read only but you still have the problem
that the file may be getting updated while you're merging
it.

[rajkumar]

I couldn't find one ....

VC++ seems to have a

fstream( const char* szName, int nMode, int nProt = filebuf::openprot
); constructor.

The third argument can used for exclusive access. I am not sure if this
is standard compliant

If you find one, I would be eager to know it as well

Raj