Wednesday, March 19, 2008 12:35 PMI need to write data to a file without locking it. Other processes must be able to delete it.
I wrote a simple piece of code:
using (FileStream fs = new FileStream("dat.txt", FileMode.Create, FileAccess.Write,
FileShare.Write | FileShare.Read | FileShare.Delete))
It works fine. When it runs, I can delete dat.txt from other process (command line, explorer, etc.).
But my code continues to write data without throwing exceptions. Why? If I delete the output file, where does my code write data? The file no longer exists.
Friday, March 21, 2008 6:26 AM
Based on your post, there is one process for writing data, others can read and delete the file. However, when then file is deleted, the write process can still running without the target file. I would like to provide you the suggestions as follows:
1. If you delete the output file from the hard disk, but you don't kill the writing process, in my opinion, you still have the output file in memory although other process have been deleted it. This may not the good design for the multi process when manipulating the file access.
2. A typical use of FileShare enumeration is to define whether two processes can simultaneously read from the same file. For example, if a file is opened and Read is specified, other users can open the file for reading but not for writing. So please consider not use all the access like Write/Read/Delete to every process. Please also consider as the same with FileAccess enumeration.
3. When you write the data successfully, you can not only add the verify code for the data, but also can kill the write process in order that the write operation and the process is stoped. Then you can have the inform code to the user that shows the end of this process. On the other hand, before you delete the data file, please make sure the file cannot be opened or written anymore. Just add some try...catch and throw exception statement to check the procedure of the project running.
Hope that can provide you some idea.
Friday, March 21, 2008 7:51 AMHello,
I want to clarify a bit. I need to write a small app that does some file and directory activity in "background". The app must run without disturbing other processes. The other process must be able to do the normal actions on file system without getting errors (read, write, delete, overwrite, modify, etc.).
I have done some investigations using ProcessMonitor by SysInternals.
I have found 2 different behaviour when I delete a file that is opened from my app: delete from Windows Explorer and from a DEL in command line. In the first case, the file is moved to the recyclebin. In the second case, a "delete request" is "linked" to the file. I both case the file is not really deleted.
In the first case, my app continues to write to a file in the recyclebin.
In the second case, my app continue to write to the original file, and the file remains locked to all the other process. No one can open/write/delete it. Also Administrator cannot use it. When my app ends, the file disappears.
Now it is a bit more clear why I can continue to write to a file that another process has deleted (or "marked" for delete).
Saturday, March 22, 2008 7:54 AM
Thanks for your reply with the clarification. It seems that not only the file in RecycleBin but also the second case, they are actually in the memory that allocated for this working process. I still suggest you to consider the suggestions in my previous post, including use the FileAccess enumeration properly in your project.