467,188 Members | 1,436 Online
Bytes | Developer Community
Ask Question

Home New Posts Topics Members FAQ

Post your question to a community of 467,188 developers. It's quick & easy.

Obtaining exclusive access to file / file lock

Sorry for aksing such a basic question but I have searched the internet high
and low and none of the solutions seem to help.

Here is my (not working) code:

FileStream fs = new FileStream(FileName, FileMode.Open,
FileAccess.ReadWrite, FileShare.None);
fs.lock(0, fs.Length);

So as you can see I am trying three different techniques at once:

* Opening the file with write access in the hope that this automatically
prevents other applications from opening the file with write access.
* Opening with FileShare.None in the hope that it would prevent the file
from being shared with other applications.
* Explicitly locking the file using the Lock method.

However, it doesn't work, other applications can still do anything they want
with the file including writing to it, renaming or moving it or deleting it.

Here is the task I want to do: On a server there are a whole bunch of files
that need to be manually annotated. To speed the process several people can
work on the files. Obviously I don't want two people to work on the same file
so some sort of locking mechanism is in order.

I also thought of another solution: Move the file from the sever to a local
directory and work on it there. However this does have the disadvantage that
if something goes wrong the file is no longer visible for the others. One
would have to make sure that such cases are caught and the file moved back to
the server.

Does anyboday have ideas?

Thanks in advance for any help!

Marcus
Jun 17 '07 #1
  • viewed: 21492
Share:
5 Replies
Well, I just tried this:

static void Main(string[] args)
{
FileStream fs = new FileStream(@"C:\httplog.txt", FileMode.Open,
FileAccess.ReadWrite, FileShare.None);
fs.ReadByte();
Console.Read();
fs.Close();
}

and it worked perfectly on Windows Server 2003. I could not even open the
httplog.txt file in notepad, let alone change it. Could you post a short,
but complete program (http://www.yoda.arachsys.com/csharp/complete.html)
showing this problem *and* on which Windows OS you are running it?

Richard

"Speedy" <Sp****@discussions.microsoft.comwrote in message
news:39**********************************@microsof t.com...
Sorry for aksing such a basic question but I have searched the internet
high
and low and none of the solutions seem to help.

Here is my (not working) code:

FileStream fs = new FileStream(FileName, FileMode.Open,
FileAccess.ReadWrite, FileShare.None);
fs.lock(0, fs.Length);

So as you can see I am trying three different techniques at once:

* Opening the file with write access in the hope that this automatically
prevents other applications from opening the file with write access.
* Opening with FileShare.None in the hope that it would prevent the file
from being shared with other applications.
* Explicitly locking the file using the Lock method.

However, it doesn't work, other applications can still do anything they
want
with the file including writing to it, renaming or moving it or deleting
it.

Here is the task I want to do: On a server there are a whole bunch of
files
that need to be manually annotated. To speed the process several people
can
work on the files. Obviously I don't want two people to work on the same
file
so some sort of locking mechanism is in order.

I also thought of another solution: Move the file from the sever to a
local
directory and work on it there. However this does have the disadvantage
that
if something goes wrong the file is no longer visible for the others. One
would have to make sure that such cases are caught and the file moved back
to
the server.

Does anyboday have ideas?

Thanks in advance for any help!

Marcus

Jun 17 '07 #2
On Sun, 17 Jun 2007 08:50:00 -0700, Speedy
<Sp****@discussions.microsoft.comwrote:
[...]
However, it doesn't work, other applications can still do anything they
want
with the file including writing to it, renaming or moving it or deleting
it.
In addition to what Richard wrote, I'll point out that if you are running
Windows Vista, and you are accessing any one of a number of kinds of
files, virtualization will cause your application instance to successfully
open the file exclusively, without blocking access by other applications
or users, because those other applications or users are not really
accessing the same file on the disk.

Another possibility is that you don't keep the FileStream around long
enough to check whether the file is locked. Note in Richard's sample, he
calls Console.Read() to make sure that his code pauses execution before
reaching the FileStream.Close() call. You're supposed to dispose/close
the FileStream instance somewhere yourself when you're done with it, but
even if you just don't keep the reference, I believe the FileStream will
eventually (and some times fairly quickly) be closed on your behalf.

Basically, the code you posted will normally lock the file. If it appears
not to, that means either it's not locking the file you think it is, or
there's something wrong about the way you're checking to see if the file
is locked.

Pete
Jun 17 '07 #3
Hi Richard,

"Richard A. Lowe" wrote:
Well, I just tried this:
Thank you very much for your help! Indeed, the code as you posted it does
work on my machine as well as it should even though it is basically the same
code I am using in my application.

So why is it not working in my application? Well I have been looking around
and finally found the answer:

The file I am trying to open and then read is a binary file. So I am
constructing a binary reader. Here is the full code:

FileStream fs = new FileStream(FileName, FileMode.Open,
FileAccess.ReadWrite, FileShare.None);
BinaryReader br = new BinaryReader(fs);
// Some code to read in the file
br.Close();
// Much more code for annotating the file

And then I keep the FileStream open in the hope that it keeps locking the
file while the annotator keeps working on it. When done I write the results
back to the file and close it.

The problem with this is that closing the BinaryReader already removes that
lock. Thus, I have to keep both the FileStream and the BinaryReader open in
order to keep the file locked.

In the hope that this might help others who are faced with the same problem,
Marcus
Jun 18 '07 #4
BinaryReader.Close closes underlying stream - see class documentation

You must keep reader open if you want to keep the lock
"Speedy" <Sp****@discussions.microsoft.comwrote in message
news:AE**********************************@microsof t.com...
Hi Richard,

"Richard A. Lowe" wrote:
>Well, I just tried this:

Thank you very much for your help! Indeed, the code as you posted it does
work on my machine as well as it should even though it is basically the
same
code I am using in my application.

So why is it not working in my application? Well I have been looking
around
and finally found the answer:

The file I am trying to open and then read is a binary file. So I am
constructing a binary reader. Here is the full code:

FileStream fs = new FileStream(FileName, FileMode.Open,
FileAccess.ReadWrite, FileShare.None);
BinaryReader br = new BinaryReader(fs);
// Some code to read in the file
br.Close();
// Much more code for annotating the file

And then I keep the FileStream open in the hope that it keeps locking the
file while the annotator keeps working on it. When done I write the
results
back to the file and close it.

The problem with this is that closing the BinaryReader already removes
that
lock. Thus, I have to keep both the FileStream and the BinaryReader open
in
order to keep the file locked.

In the hope that this might help others who are faced with the same
problem,
Marcus

Jun 18 '07 #5
If the reader doesn't have a suitable ctor / option then Jon Skeet has
a helper for this type of scenario - here:
http://www.yoda.arachsys.com/csharp/miscutil/
(NonClosingStreamWrapper; it isn't mentioned in the front page)

Get your *actual* stream; wrap that in a NonClosingStreamWrapper and
give this wrapper to the reader; the underlying stream will remain
open even after the reader has been Close()d and Dispose()d, allowing
you to use it repeatedly with different readers / writers. Just
remember to close the base stream eventually ;-p

Marc
Jun 18 '07 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

18 posts views Thread by Andre Laplume via AccessMonster.com | last post: by
reply views Thread by MSDN | last post: by
3 posts views Thread by Tom | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.