I have a ftp application. This application uses ftp rename command. If a file already exists in a directory which the file is renamed to, the error message 'the file not avaliable' caught. What can I do in c# to overwrite a file? In IIS there is a setting for this. When I do this, there is no problem.But,can I do this from c#?
What happens when there is a name collision depends on the server, if you cannot configure a known behaviour on each server you connect to you need to deal with it manually.
Either attempt a rename, catch the exception, delete the file then rename again or check for the files existence first (by requesting it size for example) and deleting it if found.
Related
Can we access a database file with non-.MDF extension using C#?
We are creating a setup project. We don't want the user to know the database details which is installed in the installation folder. So, I have tried renaming the database data file and log file with a random name without any extension.
When I have tried accessing the file from c# we are getting an error like:
An attempt to attach an auto-named database to file D:\SQLExpress\DB\abc123tmp failed. A database of the same name exists, or specified file cannot be opened, or it is located at UNC share.
Can anyone help me solve the issue?
Start SSMS, connect to (localDb)\MSSQLLOCALDB and look at the Databases attached ... I guess the File you want to attach is already attached under a different name. Detach that instance first and then your Connection should work. It's not possible to attach the same File using different Database names. The File Extension does not matter.
I'm experiencing an issue with an FTP watcher service and the File.Move method.
The FTP server is a simple IIS 8.5 FTP site and the FTP client is FileZilla FTP Client
The windows service will poll a directory where the files are to be dropped.
The first task is to rename the file, using the static File.Move method.
The second, is to copy the file to another directory using the static File.Copy method.
The issue is that while the file is being transferred, the File.Copy will [correctly] throw an IO Exception if it is used, with the message "The file is being used by another process".
However the File.Move will perform it's task without throwing any exception while the file is still being transferred. Is this the correct behavior for this method? I've not been able to find any information on why this occurs. My impression was that the File.Move would throw an exception if it's used on a file that's being used by another process [The FTP Transfer] but it doesn't seem to.
Has anyone experienced this and / or have an explanation for the behavior of the File.Move method
Copying a file requires opening it for read access. The FTP server currently has the file open such that you cannot open it for reading.
Moving a file does not require opening it for read access unless the file is on a different volume than the destination.
Since moving a file to the same volume requires only delete access and not read access, the FTP server must lock the files for read and write, but not delete.
This code shows that File.Move will indeed throw an exception if the file is in use when you try to move it, so I think your premise is incorrect.
var filePath = #"d:\public\temp\temp.txt";
var moveToPath = #"d:\public\temp\temp2.txt";
// Create a stream reader so the file is 'in use'
using (var fileStream = new StreamReader(filePath))
{
// This will fail with an IO exception
File.Move(filePath, moveToPath);
}
Exception:
The process cannot access the file because it is being used by another process.
Moving a file is effectively implemented as a mere rename and only requires write permission on the target and source directory. For a real copy you need read permissions on the file itself. As there is an exclusive lock on the source file, the copy will fail, however, the move will succeed.
I am trying to write to a file in a Asp.Net form (.aspx). I can create the file fine using,
if (!File.Exists(Settings.Default.FileLocation))
{
File.Create(Settings.Default.FileLocation);
}
But when I go to write to the file using this code:
File.WriteAllBytes(Settings.Default.FileLocation, someByteArray);
I get an exception:
System.IO.IOException: The process cannot access the file 'C:\inetpub\wwwroot\mysite.com\captured\captured.xml' because it is being used by another process.
(in this case 'C:\inetpub\wwwroot\mysite.com\captured\captured.xml' == Settings.Default.FileLocation)
I cant delete or copy the file in Windows Explorer during this time as well. However, if I stop or restart the Application Pool the WebForm is running in, the error goes away. What is the cause of this and how do I prevent it?
This is running on a Win server 2012 R2 and IIS 7.5
Read the documentation on MSDN. You should be using using statements to open the file so that you can make sure any open handles to it are closed.
using(FileStream fs=File.Create(Settings.Default.FileLocation))
{
//manipulate file here
}
Also, File.WriteAllBytes will create the file if it doesn't exist, so there's no need to separately create it.
File.Create opens the file for read/write by default and needs to be closed before it can be used again. From the docs:
By default, full read/write access to new files is granted to all
users. The file is opened with read/write access and must be closed
before it can be opened by another application.
File.WriteAllBytes will create the file if it doesn't exist, so I think your code to check for file existence and creating it is probably overkill.
Using the .NET assembly of WinSCP to upload a file. OperationResultBase.Check() is throwing the following error:
WinSCP.SessionRemoteException: Transfer was successfully finished, but temporary transfer file 'testfile.zip.filepart' could not be renamed to target file name 'testfile.zip'. If the problem persists, you may want to turn off transfer resume support.
It seems that this happens with any zip file that I try to send. If it makes a difference, these are zip files that were created using the DotNetZip library.
Code that I'm using, taken pretty much directly from the example in the WinSCP documentation:
public void uploadFile(string filePath, string remotePath)
{
TransferOptions transferOptions = new TransferOptions();
transferOptions.TransferMode = TransferMode.Binary;
TransferOperationResult transferResult;
transferResult = currentSession.PutFiles(filePath, remotePath, false, transferOptions);
transferResult.Check();
foreach (TransferEventArgs transfer in transferResult.Transfers)
{
Console.WriteLine("Upload of {0} succeeded", transfer.FileName);
}
}
Discussion over at the WinSCP forum indicates that the assembly doesn't yet allow programmatic control of transfer resume support. Is there a workaround for this?
It sounds as if the filesystem on the destination server where the file is getting uploaded to does not allow file change permissions. This could be causing the renaming of the file at the finish of the upload to fail despite the fact that the complete file was uploaded and written to the filesystem with the temporary file name used while the transfer was in progress. If you don't have administrative access to the destination server, you can test that by trying to rename a file that is already on the destination server. If that fails also, then you will either need to have the proper permissions on the destination server changed in order for that to work. Otherwise you might have to use the advice provided in your error message to turn off the resume support so it is initially opened for writing with the desired filename instead of the temporary filename (with the .filepart extension).
Turn off the resumesupport:
put *.txt -nopreservetime -nopermissions -resumesupport=off
It would help, if you included full error message, including root cause as returned by the server.
My guess is that there's an antivirus application (or similar) running on the server-side. The antivirus application checks any file once upload finishes. That conflicts with WinSCP attempt to rename the file once the upload is finished. The problem may tend to occur more frequently for .ZIP archives, either because they tend to be larger or simply because they need to get extracted before the check (what takes time).
Anyway, you can disable the transfer to temporary file name using the TransferOptions.ResumeSupport.
See also the documentation for the error message "Transfer was successfully finished, but temporary transfer file ... could not be renamed to target file name ..."
All you have to do is to disable TransferResumeSupport using the below code.
transferOptions.ResumeSupport = new TransferResumeSuppor {State = TransferResumeSupportState.Off };
My client has configured a SFTP server and monitoring the folder using FileWatcher. As soon s as the file are copied to SFTP server, client picks them.
If the connection is broke down while transferring the file, client picks the invalid file.
In between, I go for deleting the invalid file, client has already picked and delete that file from that folder.
How I can stop access for client to that file until I finish the full transaction.
There exist two generic options - upload the file to different folder and move it (you have denied this for your particular case) and upload the file with different name and rename the file once upload is complete.
If you control the server's architecture, you can do the following trick: upload the file with the name of filename..ext . The server will check the file name and know expected size. Once the file is of specified size, it can be picked and renamed by the server.
You should use a temporary folder for upload, and move the files in the monitored folder only when the file is completely upload.