Develop Reference

how delete a file completely from a Windows System

I have tried to search but I didn't found any good answer to my query.
I wanted to know how to delete a file completely from a Windows System, so that it cannot be recovered in any way.
I know there are some software's available on the internet which delete the files completely from a system. I wanted to do a small demonstration for myself and wanted to see if it was really deleted/erased from the system.
For example: If I delete a file by using SHIFT + DELETE, I know a normal user cannot recover that file. But there are recovery softwaress which can be used to recover that file. So, I just wanted to delete the file in a way so that recovery software cannot recover a particular file.
Can anyone please tell me, how this can be done? I would really appreciate. If someone can share a small piece of code that does that. I can understand it better in that fashion.
Thanks
With Regards

That is a tough one and not answerable by "a small piece of code".
Assuming you have a super secret/embarassing/illegal/whatever file you really want to get rid of. First thing is, it should have been encrypted in the first place. Just saying.
Anyway, parts or even the whole of your file can show up in a lot of places. Memory, page file, hibernate file, supposedly empty spaces on your hard drive (for example after a relocation of the file content through defragmentation). Do you have an online synchronization service? Backups? A SSD drive that spreads your file all over the physcal blocks place at every write? O dear.
So to really really get rid of that file at least on your lokal system as a minimum measure you would have to
Delete it through your API of choice (except through the normal UI which just moves it to the "trashcan")
Disable and remove the system page file
Remove the hibernate file
Overwrite all supposedly empty spaces of the hard drive with random bytes
Reboot the system
Reinstantiate the page file
But: SSDs and some hard drives have spare capacity blocks that they use as fallback when blocks produce errors. If your file happened to be in such a failed block it might have silently been relocated by the drives firmware and the drive will never write that block again by means reachable through the Windows API. So if you want to be really sure you have to physically destroy all drives the file has ever been written to.

Is it possible to be sure a certain file can be written to without opening it?

I wrote a custom control for output file name selection with the typical: text box for the filename, a "browse" button, and some other functionality specific to my application.
The text box changes color depending on the filename. If the file location cannot be written to, it turns red. If the file already exist, it turns yellow. Otherwise, it remains the system-assigned color.
To see if a file exists, I use IO.File.Exists; simple enough.
I implemented the "if the file can be written to" as a simple try-catch block where a file is actually opened, something written in it, closed, then deleted. If at any point an exception is thrown, I know the user can't use that filename and I turn the text box red.
This is a catch-all; since I'm doing the actual operation I intend to do, it is fool-proof. However, it seems irresponsible to have software creating and deleting files like crazy just to see if it can.
So my question is, how do I replicate this functionality without creating files? I can see I have to:
Check the path for legality (e.g., 'z:' is not a valid filename). This entails parsing the path and making sure all directories exist.
If the location exists, I have to check for write permissions. (Several answered questions exist to this end.)
Is there anything else?
EDIT
Within minutes I see people are already voting up an answer that criticizes that I'm checking at all that the file is accessible before actual writing to it occurs. While I appreciate experts "standing back" from my question to see whether or not there is a completely different way to achieve it, telling me I shouldn't be doing it is not an answer to my question.
So let me elaborate on my application (I am not expecting hundreds of users at the same time).
I use this file chooser control in data acquisition applications. In many situations the test that you are about to run is "expensive" in one way or another. Therefore it is critical to set things up very carefully. Overwriting data can be very expensive (and for the fearful user I have a checkbox that will append the date and time down to the millisecond to the filename).
So the purpose of my indicator colors is not to provide a surefire way for the software to know the file can be written to (that check is still done at the instant it actually has to), it's to serve as an indicator to the user that at least he has set up the file name correctly so if he goes forward he is guaranteed not to overwrite old data and he's almost sure a last-minute IO error (filename typo) won't let the experiment run unrecorded.

I suggest this - don't check anything before user commits the action. With your current approach, even if you verified the file is okay, it may be locked 5 seconds later when the user actually commits to write to a file. Doing preliminary checks may only give user a false impression of estimated success. Especially consider this point on a terminal server with 100+ simultaneous users.
There is nothing wrong with showing a prompt with Retry/Cancel/etc. if no access, and let user decide.
EDIT:
No offense, but there are standards on how such collisions are handled. Windows standard is to show a prompt to the user. Also consider this - if you suddenly have a deny in write access to the folder, which you are not expected to have, you probably need to hire another system/network administrator.
If the operation is costly, make sure this guy is paid well. C'mon, what if your network goes down during writing? Hard drive? Router? There are many reasons why writing to a file can be interrupted, and you should be prepared for that. If you cannot afford it, make sure you have invested in good infrastructure and good people to support it.
Down on earth, you can increase chances of acquiring a successful lock on the file:
Pick a unique file name, using datetime-based hash as a suffix/prefix.
Write to user's home directory, also known as %UserProfile%, it is likely that you will succeed.

I can understand your problem with not wanting to risk losing "expensive" data because the file couldn't be written and a responsible program will do it's best to avoid the situation.
I would do this by cacheing the results. Before the test is run write a mock result to a file somewhere in the user data space, then leave the file open and write the real result to the file. After this is done write it to the user-specified file. Provide a recovery option that will read the cache file and write it out to the user's file.
Your approach could fail because just because the file was writable at the start doesn't mean it's still writable. The network could have gone down. Someone could have removed the flash drive. Someone else could be doing a large data transfer through a buggy router. (Real world case--it took me a long time to prove it was a network problem and not my program. finally accepted it was their fault when I showed that dir :*.* /s on multiple machines at once would almost certainly cause one or more to fail.)

Create a Directory using Directory.CreateDirectory( ) that gives a warning message when trying to delete or rename

My application creates several text files that contain important data for its working. I am grouping up all these files in a folder. In Form_load() I gave Directory.CreateDirectory("C:\\xyz"), so that a folder is created in a drive which will later include text files, when the application will be delivered to clients. I want to see that the user does not delete or rename the folder. A dialog box that shows some warning message will be helpful. Is it possible with Directory.CreateDirectory()?

I think you should just warn the user about the importance of this directory. However, you can recreate the directory by performing this kind of check :
if(!Directory.Exists(path))
Directory.CreateDirectory(path);
From this point, you can imagine a mecanism that save the important files in a temporary way, and if the directory is deleted, you recreate it and put the previously saved files in it.

First of all, you might find reading this helpful.
Second: If I understand your needs correctly, what you want is much more painful than you think.
You should really consider doing what Damien_The_Unbeliever told you.
However, if you insist: You will need to use C++ (C# will give you and your users a lot of pain) for it, and you will need to "hook" SHFileOperation through something like ICopyHook. Start by taking a look at ICopyHook. It will be a lot of work and a lot of learning, and I don't think it's worth it, but there's the info. Good luck.

how to save user registration in the exe... (C#)

Is this even possible?
I realize that asking them to enter data when the program runs and saving it in the executable file itself is out. (Or is it?)
Right now I'm considering trying to build the program server-side with php and have it incorporate a separate text file which would contain the information. This seems marginally feasible, though I would have quite a bit of learning to accomplish it.
I was hoping for some other ideas of how I might accomplish this.
I am not interested in separate configuration or text files or putting data in windows registry. I am only looking for solutions where it can be quite-solidly a part of the executable.
Does anybody have any experience with this?
Thank you.

Its perfectly possible, that's how self-extracting zip files work.
Basically, you can add as much stuff to the end of the executable file as you want. Your program can then open its own file up on disk and read it back.

How about using Settings within your app? It depends on what you mean by "storing the user registration" as to how you would best achieve this, though. If you could give some more information about what you actually want to store, that would be useful.
An example would be to save a username, or an authentication token, and use that each time you need to check a "registration". As I say, though, the details of what to store would depend entirely on what you want to do it that data...

You could use it to embed in the unmanaged resources.

Unable to access file that is in use

I have written an Add-in for Windows Home Server Console that is supposed to copy and replace some files among other things.
The problem is that one file is already used by HomeServerConsole.exe and therefore I cannot replace it with another. I get "Cannot access file because it's being used by another process".
I'm not sure how to solve this. My first idea was to programmatically close HomeServerConsole.exe and lauch another simple program to do the replacing. How do I do that though?
Another idea was to somehow get HomeServerConsole.exe to unlock the file for me to do my thing and then handing it back to HomeServerConsole. But how?
I've also begun looking at Win32Api to solve the problem but haven't yet found a solution.
How would you go about solving it?

These methods require a reboot:
How to replace in-use files at Windows restart