Re: Exception handling?
David Ching wrote:
FileShare mode for other thread/process instances. Not the current
thread instance.
****
File sharing does not apply to threads. If you open a file
"exclusive", the handle can be
used in any thread.
****
100% of the people who need to append need to write to the file.
Sounds like another
"summer intern" design.
****
Joe, StreamWriter opens the file with Write access (duh, it is called
Writer!) and prevents other processes from simultaneously writing to it
by using Fileshare::Read (IOW, other processes can only open file for
reading, not writing). Isn't this exactly what you want and expect?
For append, it suppose to be atomic, and should allow other threads to
open in append mode for writing as well.
This is useful for session or transaction log files, for example.
I did some checking.
fopen(fileName,"at")
fopen.c has:
FILE * __cdecl _tfopen (
const _TSCHAR *file,
const _TSCHAR *mode
)
{
return( _tfsopen(file, mode, _SH_DENYNO) );
}
The RTL _SH_DENYNO translates to
fileshare = FILE_SHARE_READ | FILE_SHARE_WRITE;
in open.c
But it works because the RTL has its own internal lock file for
streaming output files. See fprintf.c which calls _lock_str() which
is a macro for _lock_file().
From what I see in the .NET SSCLI 2.0 source code for StreamWriter
there is no inherent lock for appending.
Hence, I will guess this is the reason MS created StreamWriter append
mode to use FileShare.Read.
Its probably safe with threads in the same EXE, but needs to be
confirmed with different processes appending to the same file.
--
HLS