How can I be notified of a pending file deletion?

XP SP2: A program I use frequently (Power Director 8) has a nasty habit of deleting critical, but temporary files without warning at an undetermined time. Not on computer boot, not on program initialization, but a few days after initial file creation.

How can I detect this when it happens? If I was instantly notified, I might be able to track down the reason. Something like this:

IF (file deletion in specified dir attempted)
   Notify operator

How can I do this the easiest way?

There are programs that can monitor folders/files for deletion:

Or you can try looking at the Windows event log (eventvwr.msc) to see if the incidents appear there.

Or you can run the program as a different user, or revoke write permissions to the directory in question, and see if the program throws an error message when it tries to delete the files.

A different user with different permissions is the way to go, imo.

Good to know, but too much trouble.

Too many events to wade through, and the problem won’t be detected until too late.

I have set the permissions for the specific dir (it’s always the same dir) to not allow deleting files or directories. Let’s see what happens.

Changing/creating users is a complication I don’t wish to get into. Remember, I have to use this same computer for many tasks, and I’d like to avoid nasty surprises from inadvertently modifying other programs or workspaces.

I suspect the problem is caused by a time element in the PD program rather than a specific event (or a combination of elapsed time and event). I have been watching the suspect directory, and files last accessed on 3/18 were deleted sometime today or yesterday (3/22 or 3/23). So it may take a few days before this happens again. And we don’t know if a failed attempt at deletion will cause an error or the program will just ignore it and I’ll have to sift thru the logs.

I posted a message on the PD forums, but the usual tech response is to ask me to rip off a ridiculously detailed list of system config and ask me, “Are you sure the computer is plugged in?”, so I don’t hold out much hope there.

Out of curiosity, what is a “critical but temporary” file, anyway? Aren’t temp files usually, well, non-critical and meant to be deleted soon?

For what it’s worth, it seems like running that program and letting it sit in the background would be easier than manually combing through logs all the time, but you’re the boss :slight_smile: Also, in terms of users, you don’t have to login/out every time or anything like that. Windows has a neat feature called “runas” that you can use to tell Application X to always run as user Y, while every other application remains untouched. It’s one way to sandbox* suspicious applications while still using them in your same account, in the same desktop session, no switching required. I don’t think it’s very useful for this particular instance (because permissions would accomplish the same thing with less hassle), but keep that in mind for the future…

*The sandboxing only applies to file and maybe network permissions, with additional configuration. The app can still behave maliciously in other ways – looking at your information in RAM, on screen, in other apps, etc.

It’s just the way this program works. For any project, I create a dir of my choice and put all of the working files in that – video, audio clips, JPGs, PDFs, notes, scripts, etc. to keep them all together. The video editor has an option to stretch still pix to match the aspect ratio using one of several methods – crop, expand, letterbox, etc. I discovered that if one of those is chosen, a new file is created with an auto-generated name, in the temp dir, and the original file is replaced in the script. No warning is given, and the tag/properties for this image on the script does reflect the change, nor is the temp file imported to the workspace. None of this appears to be configurable by the user.

If I return to the script a week later, I get a “not found” message for each image that was stretched (since it was automatically deleted). Since the path to the image is long, several levels deep, it gets severely truncated in the dialogue box and there is no hint as to what the original image was.

If I could configure the program, my choice would be to specify a pointer to the dir where it stores such files and never delete them. Pointer choices are available to the user for most everything else, but not this item.

So the problem is that the program treats necessary, critical files as temporary and deletes them after a few days. They should not be considered temporary.

Right now, I am copying all of the temp files to my own directory for safekeeping, and I can copy them back to the program’s temp directory as needed. That’s been working.

I just got a reply from a tech on the PD forum. He specified an option that I should uncheck (“enable file deletion”), but it always has been, and I think it’s the wrong option, anyway.

You could automate this process by using a file synchonisation utility such as DeltaCopy - (which is a Windows wrapper for the *nix *rsync *program).

It should be possible to configure this so that it synchronises new files in both directions - so new files get backed up when created, and automatically restored if something deletes them.

Thanks, Mangetout. I’ll look into that idea. I’m still trying to get past the brain-dead tech who keeps telling me to “uncheck the delete box,” which was never checked in the first place.

That program looks like it might be useful for some other tasks I’d like to automate, too.