Reading a file without preventing other processes from reading it at the same time_问答_开发者

I'm making a little app in C#/.NET that watch for the creation of a file and when it is created it gets its content, parse it and write it in another file.

Everything is working fine so far. But the problem is : there's another process that watch for this file as well. My process is only READING the file while the second one reads it and then DELETES it.

My application is making its job but when it reads the file, the other process can't read it and totally crashes (Not made by me and don't have the sources to fix it).

My application is running very fast and other open the files for a very little time to get the content and put it in a variable so it could close the file faster and then parse the content of the file which is in the variable.

I clearly don't know how but I'd like to be able to read the file and let the other read开发者_JAVA百科 the file at the same time without any hiccups. Is it possible? I still think that there will be a problem about the fact that the file is being deleted after the other app is done parsing it...

Any suggestions or ideas?

Thanks very much!

You can open the file as follows to ensure you don't lock it from other processes:

using (FileStream fs = File.Open(path, FileMode.Open, FileAccess.Read, FileShare.ReadWrite)) 
{
  // do your stuff
}

But if the other process is trying to open it in exclusive mode, it won't help and it will still crash. There's no way to deal with that other than fixing the code for the other process.

KISS: Can you have the file created in a location which the first program isn't looking at, but your software is - and when you are done processing it you then move it to the current location where the first program is looking?

Otherwise: You are going to have contention since it's going to be a race to see which process actually "notices" the file first and begins working.

I'm assuming you also don't have any control over the process creating the file?

In that case you might look at PsSuspend or PauseSp - if you can control the other process by suspending it until you are ready for it (done with the file) then that might be viable. Not sure how robust this would be.

There's also still the potential race condition of "noticing" the file and performing an action (whatever it is) - keeping the other process paused perpetually until you want it to run (or killing it and starting it) is the only completely deterministic way to achieve what you want within the constraints.

If you are using an NTFS drive (which is very likely), then you can create a hard-link to the file. Essentially, this duplicates the file without actually creating a duplicate. You can read the file with the hard-link. The other process can delete the file, which will only remove their link to the file. This will leave the file in place for you to read. When your program is done reading the file, it can delete the hard-link, and the file system will see that both links have been deleted, and it will delete the file itself.

This can be done from the command line with

fsutil hardlink create <NewFileName> <ExistingFileName>

Or you can P/Invoke the CreateHardLink function in the Windows API.

Can you create another empty zero bytes file called .reading file which has the same name but extension "reading" to it. Then once first process is done reading the file, rename .reading to .done and the second process can check .done files and delete the original file,since both .done and original file have same name but different extensions ?.

@Prashant's response gave me the inspiration for this, and it's very similar, but I believe will solve your problem.

If the other process must match a certain filename pattern

Rename the file to something that won't match first, a very cheap/fast operation
Rename it back when finished

If it matches every file in a given folder

Move it to another folder (also a very cheap operation in most filesystems)
Move it back when finished.

If the other process had already locked your file (even for read) then your process would fail, and you can make that graceful. If not you should be safe.

There is still a race condition possibility, of course, but this should be much safer than what you are doing.