Develop Reference

Why `FileShare.Read` doesn't work in combination with `FileOptions.DeleteOnClose`? [duplicate]

Language used: C#
Theory:
I want to create a file with the flag FileOptions.DeleteOnClose in a temporary folder.
The file is successfully created and I write dato onto it, the next step is to launch the application associated with the file Process.Start(...) and allow the user to inspect the document, finally I close my handle and as soon as other process close the handle to the temporary file, the file is deleted by operating system.
My problem is that other processes cannot open the file, even for reading, despite if I add FileShare.ReadWrite | FileShare.Delete to the sharing mode.
Any suggestions?

The other processes need to specify FileShare.Delete when they open the DeleteOnClose file
From the MSDN CreateFile docs:
"FILE_FLAG_DELETE_ON_CLOSE... Subsequent open requests for the file fail, unless the FILE_SHARE_DELETE share mode is specified."

Check this:
You need to make sure that all processes are opening the file with FileShare.ReadWrite and FileShare.Delete.
Even if the creator opens with share-readwrite, if a second program tries to open with share-read, the second program is basically saying no-one else can write. But the first program already has that power so the second open fails.

Switch to Linux scnr
Ok, seriously now: That is a flaw in the Windows operating system which can't really be worked around. Each program opening the file must agree on other programs having the file open in the same time. That was a problem I got many years back when I still used Windows as well. It doesn't suffice to open a file and say: Let anyone else open this as well. The others must also say open this file even if it's open already.
On Linux on the contrary, the operating system doesn't allow any file locking in the way Windows does at all. Here, if any file is used by more than one program simultaneously, the programs itself must make sure, that concurrent accesses get locked out. Additionally, on Linux, we can just create the file, make sure the other process has been started and opened the file and then just delete the file (while it is open). The filename is then removed from the file system immediatelly, but the file is still maintained by the file system driver until the last link (including open file handles) got removed.
Back to your problem: As all of this doen't work on Windows, you could do two other approaches:
Register the file to be deleted on next boot (in the Win3x days, there was a section in the win.ini for that. Newer Windows version still support that, I just can't recall any longer, how it's done now).
Start the other process, wait for it to open the file, close the file and then try each minute to delete the file until deletion succeeds ...
Regards, Bodo

Can't delete exe file even when no users are using it

I have a very simple C# application. I copy the exe file other to a shared directory where my team (only 4 of us) can use the app.
A recent problem is this, we need to update the app. So I create a new app. I then delete the exe file from the shared directory and the exe file is no longer there however if I refresh the directory it comes back. No of the other users have it open? This stops me copying over the new version.
Why is this happening? How can I check if anyone does have the app open? As you can probably tell from my post I'm not overly technical. Any help would be great.

Use Unlocker to see what locks your file and kill it.

To resolve this issue, find the process that has the open handle, and then close that process.
You can use Process Explorer or the handle command to determine which process is using the file.

Any possibility to find out unclosed streams in C# code?

I am busy writing an additional module to an existing C# application. In my module I have to generate some data and add it to ZIP archives created by the main program. (Ionic.Zip library is used). In most cases I can successfully update existing archives and store them again. But sometimes (and quite often) this does not work, since, as far as I understand, something in the main program opens a stream to the concerned archive file and fails to close it before I try to access it.
It is absolutely clear that the process that locks the files is the main program itself (tested with a tool based on How do I find out which process is locking a file using .NET?).
I am not aware of any technical possibility to trace down the point in the code where a file is opened without being (somewhere) closed, but it is my hope that such a technique may exist however and that someone could share some information on it.
TIA

Close the app.config file after reading

My "app" is being hijacked by a monitoring service. After it dies, for some reason the app.config file is considered still in use, so I can't make changes.
The only thing I can do is rename the existing file, and save a new file with the old name.
This is not an interactive app, so I want to simply want to use notepad to make changes in the file between runs.

Here is what I would try:
Use Unlocker to figure out what service or process holds a handle to your file and "unlock" it
Try ProcessExplorer. In menu go to Find > Find handle or DLL, search for your .config file and figure out what process is "taking a lock" on the file
Once you figure out what's causing this, check if you can somehow add an exception for your file, so that it's not trying to open this config file - very unlikely but an AV process may do that. Other solutions is to kill a misbehaving 3rd party app and start it once you finished editing config file.
Double check that your app was actually killed and no longer runs. Use process explorer or default task manager (or any other similar tool on non-Windows OS).

Read/writing to a file which is definitely going to be in use at random times

I need to read a text based log file to check for certain contents (the completion of a backup job). Obviously, the file is written to when the job completes.
My question is, how can I (or how SHOULD I write the code to) read the file, taking into account the file may be locked, or locked by my process when it needs to be read, without causing any reliability concerns.

Assuming the writing process has at least specified System.IO.FileShare.Read when opening the file, you should be able to read the text file while it is still being written to.

In addition to the answer by #BrokenGlass:
Only open the file for reading. If you try to open it for Read/Write access, it's more likely (almost certain) to fail - you may not be able to open it, and/or you may stop the other process being able to write to it.
Close the file when you aren't reading it to minimise the chance that you might cause problems for any other processes.
If the writing process denies read access while it is writing to the file, you may have to write some form of "retry loop", which allows your application to wait (keep retrying) until the file becomes readable. Just try to open the file (and catch errors) - if it fails, Sleep() for a bit and then try again. (However, if you're monitoring a log file, you will probbably want to keep checking it for more data anyway)

When a file is being written to, it is locked for all other processes that try to open the file in Write-mode. Read-mode will always be available.
However, if your writing process saves changes while you have already opened the file in your reading process, the changes will not be reflected there until you refresh (Close-Open) the file again.