How to read a partially locked file

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi!
I'm having problems reading a partially locked file. The writer app (a 3rd
party app) writes new data at the end of the file every second and sets a
file lock for the last record which could be 160 bytes.
My app (the reader app) tries to read the new data but since FileStream is
buffered I get IOException "the portion is locked by another process" when
trying to read an unlocked area of the file. It seems that the buffer size is
4kb. The result is a lock exception when I try to read 1 byte that is within
4 kb before the real lock and that is not nice!
Of course the FileStream should not throw a lock exception when reading an
unlocked byte with a lock 3-4 kb ahead.
Using an unbuffered FileStream should propably solve the problem, but I
cannot find such stream in .NET. The nearest I can get is to specify the
buffer size when creating the FileStream, but when specifying 0 it well be
set to 8 automatically which means that I cannot read the last 8 bytes before
the lock. And of course using unbuffered stream slows down a bit.
Obviously there is a bug in the buffered stream, it should not throw when
reading ahead.

Any ideas someone ?

Some code:
Dim fInfo as New FileInfo(filename)
Dim fs as FileStrem
fs = fInfo.Open(FileMode.Open, FileAccess.Read, FileShare.ReadWrite)
Dim br as New BinaryReader(fs)

br.BaseStream.Position(<an unlocked address>)
br.ReadByte() ==> IOException: "The process cannot access the file because
another process has locked a portion of the file."
 
Hi

I think this is by design.
Although we can consider the FileStream as Stream, it still based on the
underlying device(e.g. hard disk which is a block device). We present the
Stream, a high abstract concept, to the .NET programmer, so that they can
program again file easier. While the Stream is based on the underlying .NET
framework to read blocks of underlying data from file automatically. I
think the implement of System.IO.FileSystem's read operation is highly
depent on the buffersize member variable to decide if we need to read from
underlying win32 file handle directly or copy data from buffer. In case the
buffersize is 4k, and by calculation, we find the data should be in buffer,
but in fact the underlying buffer is not filled with 4k, then the code path
may break with unknown exception.

Also we know the space and the time is an pair of contradiction. If we need
the FileStream to act more like a stream, we need use more buffer; also if
we want to save memory, we will use less buffer and result in a more block
like FileStream. Consider if the buffersize is 4k, and we want data bigger
than 4k, so every time we read data, we need to talk to underlying win32
File handle directly which looks like we have no stream.

So I think your workaround is just OK that use a more smaller buffersize
which will cause the stream more like a block. Although minimized
buffersize is 8 bytes, I think this is because a less buffersize stream is
useless, because that will cause us to read data from hFile everytime.

If you still have any concern, please feel free to post here.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Hi

Thanks for your feedback.
I will do further research with the issue and I will update you with new
information ASAP.
Thanks for your understanding!

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Hi Lars,

I agree with you that the buffer seems to be not clever enough. Since so
far the FileStream works in this way, if you do need to change the design,
I think you may try to submit a MSWish, so that the special team will
evaluate it to see if we will do the according design change.

http://register.microsoft.com/mswish/suggestion.asp

Thanks for your understanding!

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Back
Top