I have read many other posts about this topic, but none appear to solve my problem directly (which surprises me).
Regardless...I wrote a log parser and very simply I am looking to copy a file from a remote machine locally, prior to parsing it. The file I am trying to copy is being written to constantly and I have ‘random’ success in copying it. Sometimes it will work and other times I will get an ‘access is denied’ or FileAccess error. A few other points:
Whenever I use windows explorer to copy the file locally, I never
have a problem copying it (which leads me to believe it’s perfectly
possible to copy the file 100% of the time).
I can always open the file using a text editor in its remove location.
I do not own the file being written to and do not wish to ‘lock’ it in anyway such that the application that is actually writing to this file fails.
Does anyone have any suggestions for how to copy this file?
The current command I am using is:
File.Copy(this.txt_log_file_to_analyze.Text, sLogFileToAnalyze,true);
I guess you'll have to open the file using:
File.Open(this.txt_log_file_to_analyze.Text,FileMode.Open,FileAccess.Read,FileShare.ReadWrite)
and then copy the contents of the file 'manually' i.e.
using (var from = File.Open("path", FileMode.Open, FileAccess.Read, FileShare.ReadWrite))
using (var to = File.OpenWrite("to_path"))
{
from.CopyTo(to);
}
or if .NET 4.5 see How do I copy the contents of one stream to another?
Using the above api, you can specify that you do not want exclusive access to the file.
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);
See simple unit test example below
[Test]
public void TextReaderRequiresWriteAccessToFile()
{
using (var reader = File.OpenText(Path.Combine(Folder, "Texts.txt")))
{
}
}
This test fails when I open the text file in an editor. I'd expect that the file would be opened with read privileges by File.OpenText.
System.IO.IOException : The process cannot access the file
'C:\*a location to a folder*\Texts.txt'
because it is being used by another process.
Is there a reason why .NET requires extra privileges to open a file for read via this API?
Oh, but it does only require read privileges.
The problem is that the editor prevents even read access (in .NET, that would be FileShare.None - the default for write access). If you opened the file using OpenText in both cases, rather than using the editor, it would work just fine. So you probably want an editor that doesn't lock the file (for example, Visual Studio).
It's not a problem of .NET - the editor prohibits you from opening the file for reading altogether. You might want to read up on sharing file access a bit.
When your file is open in a text editor, it has a handle open to it. That means, you need to explicitly open your file with FileShare.Read. This way, you'll get Read access while the file is already open in Read/Write mode somewhere else.
using (var reader = File.OpenText(Path.Combine(Folder, "Texts.txt"), FileMode.Open, FileAccess.Read, FileShare.Read))
{
}
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.
I have a portable executable that saves data to a file in the same folder as the executable. Is there any way that I can save data into the executable itself when I close the app?
This maybe weird, but taking the data with me and only have one file for the exe and data would be great.
Would prefer if this was made with C#, but is not a requisite.
You cannot modify your own EXE to contain stored data in anything approaching an elegant or compact way. First off, the OS obtains a lock on the EXE file while the application contained within is being run. Second, an EXE comes pre-compiled (into MSIL at least), and modification of the file's source data usually requires recompilation to reset various pointers to code handles, or else a SERIOUS knowledge on a very esoteric level about what you're doing to the file.
The generally-accepted methods are the application config file, a resource file, or some custom file you create/read/modify at runtime, like you're doing now. Two files for an application should not be cause for concern
You can, by reserving space through the means of using a string resource and pad it out. You need to do a bit of detective work to find out exactly where in the offset to the executable you wish to dump the data into, but be careful, the file will be "in use", so proceed cautiously with that.
So right now you're using an app.config (and Settings.settings) file?
I believe this is the most compact way to save data close to the .exe.
I would highly doubt you can alter the manifest of the .exe, or any other part of it.
Edit: Apparently, there might be some ways after all: http://www.codeproject.com/KB/msil/reflexil.aspx
There is one way using multiple streams, but only works in NTFS filesystems.
NTFS allows you to define alternative "named" streams in one file. The usual content is in the main = unnamed stream. It has something to do with the extra info you can see when you right click a file and check properties.
Unfortunatly C# has no support for multiple streams, but there are open source pojects that can help you.
See this link for a nice wrapper to read and write multiple streams to one single file in C#
Alternate data streams might work. By using the ::stream syntax you can create a data stream within your exe and read/write data.
Edit:
to create/access an alternate data stream, you will use a different filename. Something like:
applicAtion.exe:settings:$data
this will access a data stream named "settings" within application.exe. To do this you need to add the :settings:$data to the filename when reading or writing to the file. This functionality is provided by ntfs so it shold work in c# and should work when the application is running.
Additional information is available at: http://msdn.microsoft.com/en-us/library/aa364404(VS.85).aspx
If you want to take the data with you and only have one file for the exe and data, .zip them into a self-extracting .exe.
you can add data to end of executable file :
var executableName = Process.GetCurrentProcess().MainModule.FileName;
// rename executable file
var newExecutableName = fullPath.Replace(".exe", "_.exe");
FileInfo fi = new FileInfo(executableName);
fi.MoveTo(newExecutableName);
// make copy of executable file to original name
File.Copy(newExecutableName, executableName);
// write data end of new file
var bytes = Encoding.ASCII.GetBytes("new data...");
using (FileStream file = File.OpenWrite(executableName))
{
file.Seek(0, SeekOrigin.End);
file.Write(bytes, 0, bytes.Length);
}
// we can delete old file when exited