Delete Cache Processor Access Denied

[Kris]

Hi everyone,

I am using FFAStrans on version 1.2.0.0.

At the end of every workflow I have a command executor that is supposed to delete cache files.
With most files the processor doesn't run and I can see an error message in the status monitor "Process exited with error code: 1 (C:\Windows\system32\...__Access is denied."

Please see the settings of the command executor and the error message in the attachment.

I am using FFAStrans as application on a farm. I am logged in with a domain admin account and am able to acces all files in C:\Windows\system32 via file explorer.

I would really appreciate your help!

Regards
Kris

[emcodem]

Oh that is not good. the variable "s_cache_record" is empty in case you submit a file manually to your workflow.

This renders your batch file command actually to

Code: Select all

cmd /C "del /f /q """

Which in words says: delete forcefully and quiet all files in the current directory. Now, the current directory is c:\windows\system32 by default, so it attempted to delete all files from there.
We might talk internally about possible dangers of further advertising of this command as it is. By now, you are safe fortunately because you have UAC enabled as it seems, so deletion of the precious system files has been prevented by windows (phew what a relieve:roll: )..

[Kris]

What would be the best way to delete cache files after a workflow is done?

[emcodem]

Well i guess the default option would be to check "forget missing" in your monitor folder processor... does that work for you?

[emcodem]

Also, please let us know the "why" you are using this commandline. Where did you find this, in the forum or in the documentation of the monitor folder processor?

Damned, i just see you ask "how to delete cache files"... the term is confusing because %s_cache_record% is not anyhow connected to "cache files", it is more like the picked up filename from the watchfolder inside the brain of the watchfolder.

So to be clear.

• Check "forget" missing in your monitor component to make it forget any files that were already processed AND that are not in the watchfolder anymore. (you should always be safely able to check this because NOT checking this is for very special workflows only)

• The real "cache files" are deleted automatically when the job finishes, except you configure your workflow not to delete them in Workflow options->maintenance-> keep jobs workfolder option

[Kris]

Thank you for your help!

We have been using this, so the workflow forgets the file just like the "forget" option would do, I just wasn't aware of that option until now.

The workflows were configured a couple of years ago by a colleague that left the firm, so unfortunately I don't know where he found this.
It has all been working fine until two weeks ago, which is why I'm wondering that it start to give us error messages now.

I have read that checking "forget missing files" "will dramatically change the RAM and CPU" (https://www.ffastrans.com/wiki/doku.php ... tor_folder). We have about 100 workflows and I am a little worried that it will drastically slow down the process.

Are you familiar with this?

[Kris]

Here is a forum post, where others are doing it the same way we do:
viewtopic.php?t=767

[emcodem]

Thanks! i know we have some forum posts where this is recommended but taking into consideration that this attempts to delete system32 when you manually submit a file, i am playing with the thought to add this warning to all occurences. Steinar will probably solve this problem natively, we didnt yet finish this topic.

Good catch with the "RAM and CPU" usage for "forget missing". What happens when you check it is that in each iteration (e.g. 30 seconds), it will read each and every file in the monitors brain (cache) and see if the original file still exists. If your watchfolder contains a huge number of resident files (that were already processed), of course this action raises the duration of the watch circle and adds some business to your server.
On the other hand, if you have watchfolders that are "always empty, except a new file is dropped in", so watches that are dedicated to be used as job starter for ffastrans, you can safely use the option.

You'll want to know that the monitoring has been designed/optimized to work with really huge amounts of resident files and therefore there come some kind of "unusual" considerations with it like the option "not to forget" missing files because that can be an expensive operation under circumstances.

Let me know any doubts!