| Hi Willy,
|
| Thank you for your reply. I ended up implementing a work around.
However,
| I would like to find out more by keeping the discussion with you. If my
| writing seems "argumentative" or "accusive", my apology. I am trying to
get
| my points across.
|
| OK. Here is some of my findings:
|
| I wrote some sample codes.
|
| Sample codes 1:
|
| private void btnCmdPrompt_Click(object sender, EventArgs e)
| {
| System.IO.FileStream oFileStream;
|
| try
| {
| oFileStream = new System.IO.FileStream(@"E:\tmp\abc.txt",
| System.IO.FileMode.Create, System.IO.FileAccess.Write);
|
| oFileStream.Close();
|
| }
| catch (Exception ex)
| {
| throw (ex);
| }
|
| return;
| }
|
| This simply opens a file for write, without specifying System.IO.FileShare
| mode.
The FileStream's FileShare mode is Read by default.
I am able to open abc.txt (before Close(), I used break point) with
| Notepad.exe. However, WordPad.exe does not allow access to the abc.txt.
|
This is because Notepad at program start only needs to read the file
contents, so, it opens the file for Read Access and "Sharing" mode Read,
reads it's contents into an internal buffer and closes the file, result - no
sharing violation.
Just try to write to the file from withing Notepad, you will get a File
sharing violation because Notepad must open the file for write access in
order to flush the buffer, which obviously fails because another thread
(your progarm) has opened the file with sharing mode Read not Write or
ReadWrite.
WordPad on the other end opens the file for Read/Write access, this
obviously results in a sharing violation, because you opened the file for
shared read access only.
| Sample codes 2:
| If I change the FileOpen() to include FileShare.Read mode,
|
| oFileStream = new System.IO.FileStream(@"E:\tmp\abc.txt",
| System.IO.FileMode.Create, System.IO.FileAccess.Write,
| System.IO.FileShare.Read);
|
| Exactly the same behaviour.
|
|
This is normal, see above.
| Sample codes 3:
| If I change the FileOpen() to include FileShare.None mode,
|
| oFileStream = new System.IO.FileStream(@"E:\tmp\abc.txt",
| System.IO.FileMode.Create, System.IO.FileAccess.Write,
| System.IO.FileShare.None);
|
| Neither Notepad.exe and Wordpad.exe can open abc.txt.
|
This is normal as you opened the file for exclusive access (that is no
sharing possible).
|
| I image the legacy program must have used file open code similar to Sample
| Code 1. In this case Notepad.exe can still open abc.txt. My subsequent
| File.Open() seems to behave more like Wordpad.exe.
|
Don't see what you mean with "My subsequent ".
| What I wanted to find out was how can I simulate Notepad.exe's behaviour?
|
If the third party program has opened the file for "shared" Read only, all
you can do is open the file for Read access, the other program did not want
to share the file for Write.
|
| Back to UNIX for a bit. The way I used to lock files in UNIX was,
|
| fd = open("abc.txt", O_CREAT);
| flock(fd, LOCK_EX);
| ...
|
The same can be done in Windows, FileLock is the Win32 API which allows you
to lock a file or a file portion, but like I said the semantics of file
"locking" and file "Sharing" are different, sure you can lock the whole file
contents which results in nearly the same behavior as a ShareMode.None, but
locking (on Windows) is more dynamic as you can change the portion or unlock
the file without the need to close and re-open the file, something you can't
do with the Sharing mode.
The C run-time library has no flock (BSD) function, instead it has _locking,
but again the semantics are different, and as I said before, the libary
function calls into Win32 anyway, so _locking uses FileLock under the
covers.
| I mainly used flock() to lock a file and prvent certain sharings. Hence,
I
| do not understand your difference between "sharing" and "locking" for
files.
The Sharing mode attribute is effectively a form of file locking, but the
semantics aren't exactly the same. Sharing has much more control over what
kind of lock you want while flock (BSD) is limitted to applying locks on a
file (using an advisory lock) and is IMO not used for general file control
(lockf (System V) using fcntl, offers the same level of control on Unix).
| (Not lock() in Threading which is for multi-threading locking) Of course,
| flock() and NFS does not work too well together.
|
That's right, flock doesn't work with NFS.
Willy.