ICS_for_PDF_workdir

As long as no jobs are currently active, it is safe to manually delete the numeric subfolders under the iCS working directory.  The owner.txt file and non-numeric subfolders should be left alone.  Manual deletion is often faster than using the command in the Administrator program, but the Administrator command will leave the files in the job history subfolders untouched.

Deleting the contents of the working directory for a given job, whether manually or via Administrator, will force that job to run as a full job on next invocation.

Resurrecting an old one.....

I'm encountering disk space issues and would like to better manage the iCS for PDF working directory, rather than manually using the GUI.

Is the working directory continually increasing in size, or, does it decrease in size as jobs complete?

Is the best way to deal with disc space issues that are directly related to this folder to increase the size of the disc, or, purge methodically?

Would a deletion script keying on dates, for example everything older than a week, be of any use in managing disk capacity issues?

Thanks in advance,

jlb

Resurrecting an old one.....

I'm encountering disk space issues and would like to better manage the iCS for PDF working directory, rather than manually using the GUI.

Is the working directory continually increasing in size, or, does it decrease in size as jobs complete?

Is the best way to deal with disc space issues that are directly related to this folder to increase the size of the disc, or, purge methodically?

Would a deletion script keying on dates, for example everything older than a week, be of any use in managing disk capacity issues?

Thanks in advance,

jlb

The working directory continually increases in size as new documents are extracted.  There is no automatic pruning mechanism.  However, recent releases have included an undocumented configuration property to force deletion of the job working directory after completion, similar to the behavior of jobs submitted from ProjectWise Explorer.  The downside is more time spent copying out documents for every job run, especially for jobs containing lots of references that don't change very often.  Plus loss of delta file transfer benefits for large files that change slightly.

The property name is "DeleteJobDirOnCompletion" with value "1" in the "rendsvcConfiguration" table of the Orchestration Framework database.  It was introduced in early 2016.  I don't know offhand what release that corresponds to, but it would be fairly recent CONNECT Edition.

A scheduled task that periodically prunes the working directory is fine in theory but could get tricky.  You'd have to be careful not to delete any files currently in use by a running job -- which might be difficult to determine as a border reference copied out and unchanged for months or years could still be referenced by every active job.  Making sure the job was idle before pruning would be best, but that would require programming not just dumb scripting.  You'd also want to avoid deleting the history files if you cared about them, and definitely leave the product files in the non-numeric subfolders alone.

if your server isn't superbusy at certain times you can cheat and go back to scripting by shutting down the orchestration framework service, pruning the directories, then restarting the OF service back up.  No idea what happens if you do that in the middle of running job though.