Automatically cycle numerous or large files to the trash

I've been tasked with fixing a vendor's program that, under certain conditions, dumps gigs of junk files into a log directory. It ends up filling users' machines. My task is to figure out how to make it stop without any source code or additional running processes, and without making the program kasplode. In other words, I'm looking to use a feature of the file system to control the growth.

One idea I had was to make a hard link from that folder to NUL, as you might with /dev/null in the linux world. However, my attempts to use the mklink program to create a junction result in a message that says Local volumes are required to complete the operation.

Any ideas on how to complete the junction, or other ideas to solve the problem?

Solution 1:

No. Hard links are only available inside NTFS, and the NUL file is not an NTFS file - it's the WIN32 name of the \.\Devices\NULL namespace object, but you can't create a hardlink to it.

You could create a soft-link (a shortcut) to the NUL file if you wanted to, but I can't really think why that would be a good idea.

Solution 2:

I am just spit balling ideas here but:

If the problem program has command line switches maybe it can be turned off. I would ask the vendor first, assuming you can and haven't.

If the vendor program makes some kind of system event that windows reads, maybe you can make a script that deletes the junk folder (batch, cmd or powershell). If this is possible, remember to wait till the vendor program is done dumping.

Last resort is to set up a scheduled task to delete on windows logoff. This requires the client machines have enough space for the junk to live for the duration of the session.

If the clients are servers, thus no logoff, set it to run, say every 24 hours or how ever often this happens divided by 2. Divide by 2 is to reduce the chance of double junk so to speak..

Solution 3:

If you can persuade the program to write its log files in the root of a drive letter, say, T:, try

subst T: NUL:

because then redirection to the bit bucket works, eg things like this work:

echo > T:\some_file

What won't work are reads from the fake T: drive, folder creation and file read access. Which sorta makes sense, but maybe your app relies on those.