I have written a winform application in visual studio 2010.In one of the forms the user can browse the local system and select an image, so the application will copy that image(with File.Copy() method) to its folder.
the problem is when the user wants to delete that image(File.Delete() method),I receive an error like this :
cannot delete this file because it is used by another process.
I do not know what this error says because i do not use the image files in other processes.
cannot delete this file because it is used by another process.
The message isn't terribly helpful to programmers because when it happens when you develop code, that other process is almost always your process.
This is very likely to occur with image files, creating a Image or Bitmap object from an image file puts a lock on the file. The lock is created because GDI+ creates a memory-mapped view on the file content, a strong optimization that keeps the bitmap data out of the paging file. Matters a great deal on large images, they can contain many megabytes worth of pixel data.
That lock is kept until you explicitly call its Dispose() method in your code. So be sure that was done before you try to save the image back. In rare cases you may need to create a copy of the image to allow you to dispose the original, use the Bitmap() constructor overload that takes an Image argument.
What is happening is that when we copy a file from C# code and paste it, even after that program maintains a link/information to original/copied file. This will not happen to files not copied by program or files already present in your folder.
An alternative of this is to fire copy shell/dos command. A way to do that is present in this article
normal copy command in dos is like
copy originalfilenamewithpath destinationfilenamewithpath.
To know more about copy command go to dos and write copy /? and press enter.
Agree with what Conrad suggested, though there are edge cases where Process Explorer may not be reliable, alternatively you can try Unlocker
Related
Searched a lot, but without luck - so here goes
My C# winforms application creates temp files which are opened using the default registered application (let's call them viewer apps). Once the user is done viewing those files, I want to delete them.
Currently, I register for an Application.ApplicationExit event, to delete the file. This approach covers most of the situations but not all. Sometimes the user still has the viewing application open while exiting my app, so the success of my File.Delete depends on whether the viewer has opened the file with FileShare.Delete or not - which is out of my control.
This is what I have found so far, but fall short of what I want
FileOptions.DeleteOnClose does not help, since my app will already be closed in some cases and the temp file will still be needed. Also, when I create the file like this: new FileStream(fn, FileMode.CreateNew, FileAccess.ReadWrite, FileShare.ReadWrite | FileShare.Delete, 4096, FileOptions.DeleteOnClose), the viewer apps like say adobe reader & notepad, still complain about file in use by my application The process cannot access the file because it is being used by another process
MoveFileEx with MOVEFILE_DELAY_UNTIL_REBOOT dwFlags works, but it would wait till a reboot to delete it - I would rather have it deleted once the use is done, since reboots can be few and far between and forcing reboots IMO is not the most user friendly approach. On a side note, does windows automatically clear the %temp% folder on restart? Or is there any temp folder that windows automatically clears on restart?
I can write another background process which constantly tries to delete the temp files till it succeeds, but I would like to avoid deploying one more piece of software to accomplish this. It can be done using a windows service or scheduled task or adding command line switches to my existing app and making it run in "delete mode" in background or through task scheduler. All of it decrease my ease of deployment and use along with increasing my footprint on client's computer
In a nutshell, I am wondering if there is any Win32 API or .NET Framework API that will delete a file as soon as there are no processes with open handle to that file?
EDIT:
The information in the temp files are reasonably private (think your downloaded bank account statements) and hence the need for immediate deletion after viewing as opposed to waiting for a reboot or app restart
Summary of all Answers and Comments
After doing some more experiments with inputs from Scott Chamberlain's answer, and other comments on this question, the best path seems to be to force the end users to close the viewer app before closing my application, if the viewer app disallows deletion (FileShare.Delete) of the temp file. The below factors played a role in the decision
The best option is FileOptions.DeleteOnClose, but this only works if all files open before or after this call use FileShare.Delete option to open the file.
Viewer apps can frequently open files without FileShare.Delete option.
Some viewers close the handle immediately after reading/displaying the file contents (like notepad), whereas some other apps (like Adobe Reader) retain such handle till the file is closed in the viewer
Keeping sensitive files on disk for any longer than required is definitely not a good way to proceed. So waiting till reboot should only be used as a fail-safe and not as the main strategy.
The costs of maintaining another process to do the temp file cleanup, far exceeds the slight user inconvenience when they are forced to "close" the viewer before proceeding further.
This answer is based on my comments in the question.
Try write the file without the delete, close the file, let the editor open the file, then open a new filestream as a read with DeleteOnClose with an empty body in the using section.
If that 2nd opening does not fail it will behave exactly like you wanted, it will delete the file as soon as there are no processes with open handle to that file. If the 2nd opening for the delete does fail you can use MoveFileEx as a fallback failsafe.
We have here a windows server and one day we will get via sftp some text files in a folder. I dont have more information, but maybe this is enough. Now I should write a function that is moving these files into another folder. Well that should not be that hard, I thought... but now I realized that Im able to move a file before its finished. So I was searching for some solutions and Im really confused.
My solution would be to check the file and the processes around it. Because if the file is not finished yet, there is a copy-process and I can check this process. To make this easy, I just have to try to lock the file and if there is no another process, well then the file is ready for move?
using (File.Open("myFile", FileMode.Open, FileAccess.Read, FileShare.None))
{ /*rdy!*/ }
But now I see that people are writing something about checksum test or to test the filesize and if the filesize is not changing then the file is ready. Is this stuff not a little bit complicated? Please tell me that my solution could work also... Im not able to test it with any server to server sftp stuff. I just know that if I copy a file to another folder (via explorer) this is working. Does this work via sftp transfer as well? Any ideas? Thank you
File-size checks are dangerous - what if the upload is suspended and later resumed? How much time should go by until you accept the current file size as the final file size? => Not a good solution.
I'd go for the locking, however, this only works if the process that writes the file also opens the file in a way so that it is locked exclusively. If the process doesn't do that, you'll be stuck with your problem again.
Another solution would be to upload the files with temporary names, like ".sftptmp". And to have the uploader rename it after it is done. That way you can be sure the file has been uploaded - just ignore all files that end with ".sftptmp". This, however, assumes that you actually have control over the process of uploading files.
Another option is to have the sender put a control file after the data file. For example, put uploadfile-20220714.txt, then put uploadfile-20220714.ctl. The control file can contain file information such as the name and size of the data file. This option requires the sender to modify their process, but it shouldn't require too much effort.
I have a service running on a webserver that waits for a zip to be dropped in a folder, extracts it, and then moves it to a certain directory. Since we want to replace the directory in question, it renames the existing folder (very large folder, takes a couple minutes to delete), then moves the extracted files in its place, then deletes the old folder. The problem is: when it tries to rename the existing folder, it gets 'Access to the path '<>' is denied.', I believe because the folder is in constant use by the webservice. Is there a way I can force the folder to rename, or take control and wait for it to not be in use? Or is there another way I can accomplish this goal?
You can't "force" a rename while any process holds an underlying operating system handle to the folder(it would be horrible if you were able to do that).
You can:
Implement pause/resume functionality for the webservice so it can be told to pause its work and release the handles, then resume after you are done.
or
Stop the webserice completely, do your work, then start the webservice
What does one need to take care of when creating a method to move (cut) a batch of file from one directory to another?
Let's say the method signature is Move(filter, sourceFolder, destinationFolder, overwrite). What do I need to take care of to avoid the risk of data loss especially when overwriting the original file and deleting of the source file is taken into account?
Several possible scenario I am worried of: error occurs when a move is in progress, moved a file but the file are somehow corrupted, deleted a namesake file in order to allow the new file to move but then error happens when moving the new file, etc.
I'm using .net's System.IO namespace for the move operations.
Without transactions, the safest way is to copy, verify and then delete. It is up to you if you want to move per file (this is how windows does it, a move operation can fail leaving you with half of the files moved) or to allow only the entire batch to be moved, or none at all.
You would have to make decisions on how to respond to files that have been modified during the move, source files that cannot be deleted afterwards, or destination files that have already been opened when you're performing a rollback.
Is there a way to display the contents from memory directly in a Notepad window?
I'm assuming that I understand your question. If the file already exists on the machine you can execute the following:
System.Diagnostics.Process.Start( "notepad.exe", "[PATH]\[FILE].txt");
If not then save the file locally and then run the above code.
Double-click on the file, making sure the association is set to Notepad.
If you want Notepad to show it without saving it to disk, you can open an instance of Notepad, get the handle for the window, then write the text directly into there. You will need to use Windows User APIs to do this.
The easiest way to accomplish this is to save the file and open it in notepad, however there are at least two other ways.
Open Notepad then copy what you want to the clipboard, then using DDE force Notepad to paste. This is bad, because it potentially overwrites what the user may have been doing in the clipboard.
The second way involves getting a window handle to the notepad Edit control, then doing a WM_SETTEXT to the window. This will not, however, work across privilege boundaries (such as for apps that run as administrator, but notepad runs as a normal user). This also involves getting down to Native level and doing P/Invokes. Not exactly an easy method.
Frankly, it's just easiest to save it to a file and load it.
Why do you need notepad to show some contents (which is in memory)?
If you are using winforms, you could put it in a textbox.
Sorry, if I have not understood your question correctly.
I would like to add to MrEdmundo's answer that the Isolated Storage is the right place to store the temporary txt file for Notepad.