possible for FileStream lock not released on close ?

  • Thread starter Thread starter John A Grandy
  • Start date Start date
J

John A Grandy

Has anyone ever experienced creating a FileStream with no shared access ,
writing to the file , and then closing the FileStream , but there is a delay
in the lock being removed ?

So, code might be :

FileStream stream = File.Open( filePath, FileMode.Append, FileAccess.Write,
FileShare.None );

BinaryWriter writer = new BinaryWriter( writer_fs_datetime );

writer.WriteLine( "whatever" );

writer.Close();

// .... other stuff ....

// some other code attempts to read from or write to file but gets access
denied error
 
Has anyone ever experienced creating a FileStream with no shared access ,
writing to the file , and then closing the FileStream , but there is a
delay
in the lock being removed ?
Click to expand...

The only time I've seen something like that is when something else in the
OS is accessing the file as a result of the change. For example, you've
got a thumbnail view visible in Explorer and changing the file results in
the thumbnail being updated.

Without a concise-but-complete code example that reliably demonstrates the
specific problem, it would be hard to pinpoint an exact cause.

Pete
 
Has anyone ever experienced creating a FileStream with no shared access ,
writing to the file , and then closing the FileStream , but there is a delay
in the lock being removed ?

So, code might be :

FileStream stream = File.Open( filePath, FileMode.Append, FileAccess.Write,
FileShare.None );

BinaryWriter writer = new BinaryWriter( writer_fs_datetime );

writer.WriteLine( "whatever" );

writer.Close();

// .... other stuff ....

// some other code attempts to read from or write to file but gets access
denied error
Click to expand...

Have you considered moving your code into a using statement?
 
* John A Grandy wrote, On 15-9-2009 20:53:
Has anyone ever experienced creating a FileStream with no shared access ,
writing to the file , and then closing the FileStream , but there is a delay
in the lock being removed ?

So, code might be :

FileStream stream = File.Open( filePath, FileMode.Append, FileAccess.Write,
FileShare.None );

BinaryWriter writer = new BinaryWriter( writer_fs_datetime );

writer.WriteLine( "whatever" );

writer.Close();

// .... other stuff ....

// some other code attempts to read from or write to file but gets access
denied error
Click to expand...

The Index server process, thumbnail generation process and any other
process lurking around waiting for changed and new files might be the
one holding the lock. WinTernals/Systernals used to have a tool that
shows which process is holding which file. The name of the tool escapes
me, but since Microsoft has bought their tools, you should be able to
find it on the Microsoft download website.
 
I think this is on the right track.

These files are being written to a Samba-shared drive on a Linux box.

So potentially the Samba external process is sensing the new/changed files
and temporarily placing a lock on them ? But for what purpose ?

So, actually it's not the FileStream lock that is persisting beyond the
BinaryWriter.Close() , rather it's a new lock put in place by the external
process ...
 
I think this is on the right track.

These files are being written to a Samba-shared drive on a Linux box.

So potentially the Samba external process is sensing the new/changed
files
and temporarily placing a lock on them ? But for what purpose ?
Click to expand...

Could be anything.
So, actually it's not the FileStream lock that is persisting beyond the
BinaryWriter.Close() , rather it's a new lock put in place by the
external
process ...
Click to expand...

Are you sure? The "another process has the file locked" exception is the
same, whether that "other process" is actually the same one or not.

The tool Jesse is thinking of is FileMon, but the functionality has been
folded into the Process Explorer program, still available through the
Microsoft Technet portal for the SysInternals stuff:
http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

With that, you should be able to use the "Find/Handle or DLL..." menu
command to discover what process locally has a lock on a specific file.
Note, however, that if the file is on a remote computer, that won't
necessarily show you any locks on the file, as the locks could be only on
the remote computer. You should be able to use the "lsof" command on the
Linux computer to learn what has the lock there, but obviously you'd have
to be quick and catch it right when the file is being accessed.

One thing FileMon did that Process Explorer doesn't appear to is to report
file operations as they happen. I don't know if there's an equivalent for
Linux, but if there is, you can just set that up to log what goes on and
then check it after the fact to see if you can figure out what's accessed
the file, locking it.

Pete
 
Without a concise-but-complete code example that reliably demonstrates the
specific problem, it would be hard to pinpoint an exact cause.
Click to expand...

I would second that. It seems the full code for a repro would be about 10
lines and could perhaps help...

In the code snippet you show :
- the binarywriter doesn't seems to use the filestream
- the filestream is not closed
etc...

So it is still a bit early to phase out a programming error...
 
* Peter Duniho wrote, On 16-9-2009 2:33:
Could be anything.


Are you sure? The "another process has the file locked" exception is the
same, whether that "other process" is actually the same one or not.

The tool Jesse is thinking of is FileMon, but the functionality has been
folded into the Process Explorer program, still available through the
Microsoft Technet portal for the SysInternals stuff:
http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

With that, you should be able to use the "Find/Handle or DLL..." menu
command to discover what process locally has a lock on a specific file.
Note, however, that if the file is on a remote computer, that won't
necessarily show you any locks on the file, as the locks could be only
on the remote computer. You should be able to use the "lsof" command on
the Linux computer to learn what has the lock there, but obviously you'd
have to be quick and catch it right when the file is being accessed.

One thing FileMon did that Process Explorer doesn't appear to is to
report file operations as they happen. I don't know if there's an
equivalent for Linux, but if there is, you can just set that up to log
what goes on and then check it after the fact to see if you can figure
out what's accessed the file, locking it.

Pete
Click to expand...

Pete, thanx that's the tool I was talking about. It's even possible to
integrate that directly into explorer nowadays:

http://www.winhelponline.com/blog/view-open-handles-to-a-file-or-folder-from-the-context-menu/
 
Back
Top