Page 5 of 6
Doing the Delete
The user has to run the TimeDelete application directly, i.e. not from the SendTo menu, to scan the list of files and delete any that have expired. The first thing we need is the path to the data file and this is a matter of reading the Shortcut again to obtain the target path:
private void button3_Click(
object sender, EventArgs e)
string SendTo = Environment.
WshShellClass WshS = new WshShellClass();
IWshShortcut Shortcut =
string ProgramPath =
Now that we have the path we can open the data file. This time we have no choice but to use a more standard approach to file handling and use a Streamreader – but the File object still provides an easy way to get one:
We also need to know the current date to compare to the delete dates in the file:
DateTime now = DateTime.Now;
The simplest way of scanning the file is to use a do loop with a test at the end for the end of file condition:
Reading in a line and parsing it into its separate items couldn’t be easier:
String Line = FileList.
The Split method returns a string array with each item in a separate element. Element  specifies the delete date and this is easy to convert to a date and test against the current date:
DateTime DeleteTime =
if (now.CompareTo(DeleteTime) > 0)
If the file’s lifetime is up we need to process it. The second element determines if a prompt is to be issued or the file just deleted:
DialogResult action =
"Delete " + Line + "?",
if (action == DialogResult.Yes)
Notice that we are using the File object to do the delete – what did we do before it was invented?
If the file’s time isn’t up we simply copy its data line to a new file called DeleteDate.T$$:
ProgramPath + @"\DeleteData.T$$",
String.Join(",", Line) +
} while (!FileList.EndOfStream);
We have to close the stream explicitly in this case. Also notice the use of the Join method to rebuild the line from the separate elements in the string array. When the do loop comes to and end all of the lines of the file have been processed, the files have either been deleted or not according to what the user selected, and all of the data lines corresponding to files that are still in date have been written to the new file.
The final task is to juggle the file names around so that the new file replaces the original. There are lots of ways of doing this but what you have to keep in mind that you don’t want to arrive at a state where there isn’t a backup file on the disc so one way of doing it is:
ProgramPath + @"\DeleteData.$$$");
@"\DeleteData.T$$", ProgramPath +
That is, first delete any existing file ending .$$$, then rename the .TDD file to .$$$ to create a new backup, and finally rename the temporary .T$$ file to .TDD. In this way the user has a backup of the list in the .$$$ file and during the swap over there is always one copy of the data left on the disk. You can try to work out what is the worst state the system can be left in if the process crashes before completion but to do the job better takes a lot of effort.