Read and Write a file at the same time?

[Lost User]

Tony4966 wrote:

Is there anyway of getting around this?

The easiest way that comes to mind is to replace the file with a desktop database. You can read/write into the database from multiple points, and export the parts to CSV if you need them.

I are Troll :suss:

[PIEBALDconsult]

The program that writes the file needs to allow other processes to read it; this is done when the stream is opened. But, really, this is unlikely to be a good design. Do you really want the file? Or are you only trying to have inter-process communication? If you don't actually need the file; then find a better way.

[Tony4966]

You are right. This is probably not a good design but I just want to get this working as quickly as possible and it is just a short term solution. So please can you be a little bit more specific about how exactly I let the program that writes into the file allow other programs to read the file at the same time? A quick example of would be

string path = @"C:\Documents and Settings\";

        string filename = "tester.csv";

        TextWriter writer = new StreamWriter(path + filename, false);
        
        for (int j = 0; j < 10; j++)
            writer.WriteLine("{0}, {1}", j,2 \* j);

Many thanks indeed.

[Alan N]

Hi, You will have to drop down to the FileStream level to open the files in the correct manner. The writer should open the file with FileAccess.Write and FileShare.ReadWrite. The reader will obviously use FileAccess.Read but perhaps not so obviously must also specify FileShare.ReadWrite, otherwise the open will fail with exception that you have already seen. The writer must flush the stream after each write operation to ensure that the latest data is available to the reader. The writing code will be something along these lines:

FileStream fsw = new FileStream("filename", FileMode.Open, FileAccess.Write, FileShare.ReadWrite, 8, FileOptions.WriteThrough);

  ....
  ....

// Encode string
Byte[] buff = Encoding.Default.GetBytes("Data to write");
fsw.Write(buff, 0, buff.Length);
// flush to ensure the data is written to disk
fsw.Flush();

The reader should open the file thus:

fsr = new FileStream("filename", FileMode.Open, FileAccess.Read, FileShare.ReadWrite);

That's the basics of it, assuming that there is only one writer. If that's not the case then you will need to look into locking the file. Alan.

[Ghydo]

You can create a FileStream that allows read access using this[^] constructor:

Stream stream = new FileStream(path + filename, FileAccess.OpenOrCreate, FileAccess.Write, FileShare.Read);
TextWriter writer = new StreamWriter(stream);

Also it is a better pratice to dispose of the stream, enclosing them with the using keyword.

[dojohansen]

Consider using a message queue. It is robust and flexible, performs well, supports asynchronous processing (if desired) and doesn't take a lot of code so should be as quick to get up and running as messing with the files.

[abiemann]

a service with a queue seems like an awesome idea for production code; you could add logging and keep adding all sorts of features as the requirements of the other applications change. I personally have used a MemoryMapped file to exchange data between two applications because I hate using the HDD for temporary data. EDIT: for an example of a memorymapped file: http://msdn.microsoft.com/en-us/library/dd997372%28VS.100%29.aspx[^]

modified on Monday, November 23, 2009 6:45 PM

[Luc Pattyn]

I concur with Alan. That is the way that has worked for me many times already. :)

Luc Pattyn [Forum Guidelines] [My Articles]

---

I only read code that is properly indented, and rendered in a non-proportional font; hint: use PRE tags in forum messages

---

[dojohansen]

I suppose a memory-mapped file is faster if there is a very large number of interactions. And I don't think message queues are installed by default on non-server editions of Windows, at least not XP. If performance is paramount there's probably nothing that can beat shared memory! On the other hand message queues are extremely flexible. It's straightforward to share one between any number of applications (either as producers or consumers), it supports distributed transactions, the apps and the queue itself can be on the same or different computers, running the same or different Windows versions, there is built-in support for preserving a message log, they can be easily used synchronously or asynchronously, and .NET has all the wrappers needed to make it easy to work with them. Wikipedia (usually good for getting an overview) http://en.wikipedia.org/wiki/Microsoft\_Message\_Queuing MSDN (usually good for reference, rather variable IMO on describing "the big picture") http://msdn.microsoft.com/en-us/library/ms978425.aspx [EDIT: changed the MSDN link to one about .NET and MSMQ; originally linked to Win32 doc.]

[Paulo Zemek]

If you don't need the file, but want to work with the "stream" behavior, use NamedPipes. See the classes NamedPipeServerStream and NamedPipeClientStream. They are easy to use and are created for interprocess communication.

[Tony4966]

Thanks so much for so many excellent replies. I appreicate all of them I finally 'have to' give up this 'bad' design because I can get it working but it's very messy and probably not worthwhile spending too much time on it. Just a quick note; I get writer part working like this, which is enssentially the same as suggested.

string path = @"C:\Documents and Settings\";

string filename = "testernew1.txt";

var fi = File.Open(path + filename, FileMode.OpenOrCreate, FileAccess.Write, FileShare.ReadWrite);
var sw = new StreamWriter(fi);
for (int j = 10; j < 0; j--)
sw.Write(j);
sw.Flush();
fi.Flush();
sw.Close();
fi.Close();

Apparently, the reader part is very simliar. I am not familiar with message queque so I am going to look into it; also someone told me that it also be done by using remote charting which I assume is more complicated than message quque? Anyway, it would be great if someone can show some examples of either using message queue or remote charting. Thanks again for all the replies!