I'm using MS logging application block for logging my application event into a file called app-trace.log which located on the c:\temp folder.
I'm trying to find the best way to read this file at runtime and display it when the user asks for it.
I have 2 issues:
It seems that this kind of feature is not supported by the framework, hence I have to write this reader myself. Am I missing something here? Is there any better way of getting this data (w/o buffering it in the memory or saving it into another file)?
If I'm taking the only alternative left for me, and implementing the reader myself, when I'm trying to do:
System.IO.FileStream fs = new System.IO.FileStream(#"c:\temp\app-trace.log", FileMode.Open, FileAccess.Read);
I'm getting "File being used by another process c#". Probably the file is locked by the application block. Is there any way to access and read it anyhow?
You are correct that Enterprise Library does not support this.
If you must retrieve the data from file then you should be able to do it by using the following:
FileStream fs = new FileStream(#"c:\trace.log", FileMode.Open, FileAccess.Read, FileShare.ReadWrite);
I'm curious why the users need access to the log files? Is it for support? If this is a server application, then I would probably seriously consider logging to a database and then retrieving the data from the database when the user wants to view the log information.
Related
I am having a spot of bother trying to save a dummy file to the nul device in an ASP.Net (.Net 4.5.2) application. When I get the the point where the application tries to save the file, it throws an exception.
The file's path is set to "nul" (sic), and when it is saved I get the following exception message:
Access denied to file "\\\\.\\nul"
Is it possible using .Net (C# in my case) to save a file to the nul device from within a web application?
In case you are wondering, saving the file is merely a trigger for another action. I am not interested in the saved file itself, and I want to avoid the code overhead of having to create and later delete a uniquely named dummy file - hence saving it to the nul device.
TIA
This answer on MSDN suggests you can't do this with the .NET file handling API:
While the Win32 CreateFile method will open devices, alternate streams, etc, somewhere along the line it was decided that the .Net File implementation would be restricted to traditional files. Probably not what you wanted to hear.
social.msdn.microsoft.com/Forums/vstudio/en-US/43163abb-4e82-4a7d-b614-29eb7914bdba/nul-filename-in-net
use the flag that deletes filestream on close...
new FileStream(TempFileName,
FileMode.CreateNew,
FileAccess.ReadWrite,
FileShare.ReadWrite, 512,
FileOptions.DeleteOnClose);
I have a Python service spitting out logs to text files. It rotates them every ~400KB. So the Python service opens up a handle on the file, let's call it app.log. It then writes content to the file every now and again flushes it to the disk. When it reaches a certain size, it closes it's handle, and move it to app.log.1 and starts a new handle on app.log.
So I can't change this service, but I have a C# application that will read those logs. I ran into 3 scenarios:
If I just try to read those those logs using new FileStream(path, FileMode.Open);, it won't allow me as the Python service has an handle on it.
If I try to open it using new FileStream(path, FileMode.Open, FileAccess.Read);, this allows me to read it, but if the service tries to rotate the log, it won't be able to as my C# application now has a handle on the file.
And if I try to open the file using new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.Delete);, my Python service won't fail on deleting the file, but it will fail creating a new handle on app.log as the C# application would still have a handle on it.
The only solution which I'm aware of would be using Windows Shadow Copy (VSS) to create a snapshot of the logs and then read that snapshot but this would be quite expensive as we need to query the logs at every 5 minutes.
Also, I'm not interested in reading the rotated logs, app.log.1, app.log.2 etc.
Logging to text files under Windows seems to be a pain what with all the locking/handles. Does anyone have any suggestion?
You should be able to open your file as Dmitry Popov suggested in his answer as below and not affect Python writing to it, however it depends upon what locks the Python application holds on the file, it can lock you out completely and there is nothing you to do to prevent that without hacking Windows.
FileSream fs = File.Open(#"c:\Test.txt", FileMode.Open, FileAccess.Read, FileShare.ReadWrite | FileShare.Delete)
The FileStream object created in this way will still be connected to the same file after an operating system file move operation has been performed on it to rename it.
So lets assume your python app opens a file called Test.log and starts writing to it. You can read any data written to it (after python flushes its buffer) using the file stream returned from the line above. The python application can close and reopen the file as often as it wants writing each time and the reading application will remain connected to it. When the python application issues a File Move operation to rename the file to Test1.log, the file stream returned above will still be connected to the file which is now called Test1.log so you can continue reading to the end of the file before starting the new log file if that is what you want. There is one caveat to this. The Python application needs to use a Move/Rename operation rather than copying the file to a new one and deleting the old one, I'd be surprised if that is what it does though.
There is a possibility that your reading application will reach the end of the file before your writing application has finished reading from it. In this case fs.Read will keep returning 0 after a timeout until the writing application opens the file and writes some more. You can make the time out very long / infinite if you want.
As you don't want to read to the end of one file before starting the new one you could just close and reopen the file at regular intervals. The log file without the numeric suffix should always be the most recent.
If however you want your reading application to read to the end of one log file before starting at the beginning of the next one you will need to work out when the writing application has finished writing to the log file. Also it needs to find out what the file is now called so it can read n-1 next. Is there some marker written by the python application that you could look for to denote the end of a file? Does it write 'End Of Log' or something similar?
Be warned also that there are going to be short periods of time when LogFile n-1 does not exist. This is because if you have log files 0, 1, 2 and 3 it needs to make log file 3 into log file 4 before it can make log file 2 into log file 3. While it is doing this there will be a short period of time when you have log files 0, 1, 2, 4 and no 3.
Personally I would find the developer that wrote the logging for your Python application give him/her the evil eye for causing this headache in the first place. What is wrong with having the most recent log file have the largest number?
using (FileStream fs = new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.Read))
{
//Do works
}
C# thread don't lock the file in this case, your Python script can write and close the file to create another one without deadlock.
You can combine FileShare flags:
FileShare.Write | FileShare.Delete
Here's a demo:
using (var cSharp = new FileStream(filename, FileMode.Open, FileAccess.Read, FileShare.Write | FileShare.Delete))
{
// The Python service will be able to change and to rename the file:
using (var python = new FileStream(filename, FileMode.Open, FileAccess.Write, FileShare.Read))
{
}
File.Move(filename, newFilename);
}
You will have to deal with concurrency. You can use FileSystemWatcher to monitor file changes.
I'm reading a file which is periodically being written to by a 3rd party program.
Im reading using the below FileStream:
using (FileStream fs = new FileStream(
FullPath,
FileMode.Open,
FileAccess.Read,
FileShare.ReadWrite))
However the 3rd party program is writing to the file but is using the FileShare.None
So occasionally I've got the file open for reading when the 3rd party program tries to open the file with exclusive access but fails.
How can I read this file without causing problems for the 3rd party program?
I wouldn't mind releasing my read to give priority to another application. Any way to do this?
What you want to do is monitor for process creation notifications, and when you see the specific process come into existence, you will want to get out of its way.
IWbemServices::ExecNotificationQuery
Here are some some additional details off of MSDN.
Here is also a CodeProject: Process Information and Notifications using WMI
If this 3rd party proccess (.exe, windows service, web app, etc.) ever stops, you could access the file when that happens, if it never stops or it's impossible to tell when it will run, you could do a copy this file as soon as you turn on the server.
This will be valid or not depending on the nature of your app and the other one, and on how often you need to read this file.
While I haven't used it, have you tried use the System.IO.Filestream.Unlock method to help you stream parts of the file that are not currently locked by the other software? I'll just assume the other software isn't locking the whole file.
I am building an application in C# in which I have to open a CSV file to read data from it. I get an exception when I try to open the CSV file from C# when that file is already open in Excel. The exception says that the process cannot access the file since it is already open. How can I solve this problem and open the file even if it is opened in other application?
Thanks,
Rakesh.
I faced this problem some time back.
You are missing the FileShare parameter. Without specifying that, if you open a file, it will be locked exclusively by your application. But since it's already been opened by Excel (or any other app), you will receive an exception.
You can try using this - I think this will be your best bet -
using (FileStream fs = File.Open(<file-path>, FileMode.Open, FileAccess.Read, FileShare.Read))
This code says: Hello Excel! If you may permit (read, not throw exception), I would like to read the file, though I will not try to own it and I know that you may modify it anytime.
If this throws error, then Excel has denied you even the read access. Too bad then!
All the best.
It is possible but you have to carefully control the file sharing you specify. Most .NET classes default to FileShare.Read, denying another process from writing to the file. But that cannot work if the file is opened by Excel, it already gained write access to it. You cannot deny a right that was already acquired.
To fix the problem, make your code look similar to this:
using (var fs = new FileStream(#"c:\\temp\\test.csv", FileMode.Open,
FileAccess.Read, FileShare.ReadWrite))
using (var sr = new StreamReader(fs)) {
// Read it...
}
Note the use of FileShare.ReadWrite. I verified this code works while Excel had test.csv opened.
Beware of the potential trouble you'll invite with this, odd things can happen when Excel writes to the file just as you are reading it. You'll likely read garbage, part of old data, part of new, without a good way to diagnose this.
Due to concurrency issues you can not have the option to write to two instances of the same file. It should be possible to open one as read-only this would allow for there to not be a concurrency issue as reading is guaranteed to be thread safe. This article should explain how to do what I proposed
That's not possible.
A file can be opened with different kind of protection. Excel opens the file exclusively, for the purpose of protecting the file from being changed by some other program and then reverted back when Excel saves it.
Excel could have opened the file and allowed reading, but then you could end up in a deadlock situation where two applications have the file open for reading, and neither can save anything back to it.
Another solution, suggested by this answer, is to copy the file to a temporary file and open that.
Use
System.IO.File.Copy(sourcepath, copypath, false);
This question already has answers here:
How can I read a file even when getting an "in use by another process" exception?
(4 answers)
Closed 6 years ago.
I have a small problem. I have a tool which should parse a log file daily, unfortunately this log file is in use by the process which writes to the log and I cannot stop it.
First try was to create a copy of the file, which is not working either.
Is there any way for me to read the current text of the log file, even if it is already in use?
using (FileStream stream = File.Open("path to file", FileMode.Open, FileAccess.Read, FileShare.ReadWrite))
{
using (StreamReader reader = new StreamReader(stream))
{
while (!reader.EndOfStream)
{
}
}
}
The FileAccess specifies what YOU want to do with the file.
The FileShare specifies what OTHERS can do with the file while you have it in use.
In the example above, you can open a file for reading while other processes can have the file open for read/write access. In most cases, this will work for opening logfiles that are in use.
You are at the mercy of the program that is writing the file. In Windows, a process can open a file for reading, writing or both, but it can also control whether other processes can open the file for reading, writing or both. If the other process has denied you the right to read the contents of the file, then there is nothing you can do about it.
If you control the source code of the program that is writing the log file, then change it to allow read access by other processes.
Use File.OpenRead(path), this allows you to access a readonly stream to the file; that way you won't be bothered if another application has a write lock on the file.
it depends, have you tried reading the file in read only? using one of the static methods
System.IO.File.ReadAllText(path) or System.IO.File.ReadAllLines(path)
they may work if there file isn't locked exclusively
I highly recommend BareTail, which we use to look at all of our logs in real time. Also supports highlighting, which is very useful.