Exception handling?
in [MFC]
|
Prev: Deriving from a class derived from a CDialog
Next: How to show underlined menu shortcut letters by default for a contextmenu ?
From: David Ching on 23 Jun 2010 18:03 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:h00526hra3tc9it2ptporviio92hpqagvs(a)4ax.com... >>>> This is not the case any more with .NET. The StreamWriter constructor: >>>> >>>> StreamWriter(string filename, bool Append) >>>> >>>> opens the file in FileShare.Read mode only. >>> **** >>> How do you append if it isn't opened in Write mode? Did somebody >>> perhaps misread the >>> specifications? >> >> >>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? -- David
From: Hector Santos on 23 Jun 2010 18:50 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
From: Joseph M. Newcomer on 23 Jun 2010 18:56 See below... On Wed, 23 Jun 2010 15:03:56 -0700, "David Ching" <dc(a)remove-this.dcsoft.com> wrote: >"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message >news:h00526hra3tc9it2ptporviio92hpqagvs(a)4ax.com... >>>>> This is not the case any more with .NET. The StreamWriter constructor: >>>>> >>>>> StreamWriter(string filename, bool Append) >>>>> >>>>> opens the file in FileShare.Read mode only. >>>> **** >>>> How do you append if it isn't opened in Write mode? Did somebody >>>> perhaps misread the >>>> specifications? >>> >>> >>>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? **** It sounded like the description was that it opened only with read sharing for append. Typically you open for read/write because you can't append without write access, but while you are writing, anyone else should be free to write in non-append mode. So if I am adding record 703, there is no reason to prevent anyone from (re)writing records 0..702. That's why file locks exist. And they can lock the range of record 703. joe > >-- David > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Hector Santos on 23 Jun 2010 19:10 Joseph M. Newcomer 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. > **** Yes, but we are not opening the file in exclusive mode because the basic idea is to allow shared appending with other external process threads as well. For that you need allow for the FILE_SHARE_WRITE bit. In the C RTL for fopen(), you will see that using "at" opens the file with the eventual CreateFile() call share mode bits: FILE_SHARE_READ | FILE_SHARE_WRITE The point here is that .NET defaults to only FILE_SHARE_READ when opening a StreamWriter class constructor with the boolean append mode option. StreamWriter sw = new StreamWriter("Shared.log",true); // true for append Luckily, the StreamWriter class has a constructor overload for passing in a file stream object where you can be specific with the open mode, access mode and share mode. -- HLS
From: David Ching on 23 Jun 2010 19:34
"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:8445269je2c1ekr6ukuj6g0e5gcj9iv2ar(a)4ax.com... > while > you are writing, anyone else should be free to write in non-append mode. > So if I am > adding record 703, there is no reason to prevent anyone from (re)writing > records 0..702. > That's why file locks exist. And they can lock the range of record 703. Interesting, thanks. I hadn't thought of allowing other processes to rewrite existing data while only you could append new data. That seems like it would be rarely used, perhaps that is the comment you got about only 5% of the people needed to do that? -- David |