A user had this error yesterday, just wanted to point it out. It appears that there's an error in the unique filename creation once you get to 10001 apex files with the same task name. Seems a little crazy that it should get that full, but end users don't know they need to purge the directory.

Obviously something needs to be fixed there, but I would also take a look at the Preview Preferences retention period. It's doubtful that retaining that many files would have any use, since how would one identify the file of interest?

The default retention period is 96 hours; maybe it should be reduced to 24 hours for this user?

In the meantime I'll track down the bug...

Actually, considering that it has to look up each one of these potential files to see that it already exists (in other words, it is doing 10,000+ lookups for each new file in this case), I think it would be a good idea to just have it wrap around from tskaaa-99 to tskaaa-1 and start overwriting. That would still give you 99 copies of each same-named print file, which would seem to be more than enough for any reasonable retention/recovery purpose.

Note that this still doesn't prevent you from accumulating thousands of files in the APEX retention directory (since you could have up to 99 copies for each original print file name), it would limit the amount of time wasted trying to find the next unused -## suffix.

The fix will appear in 6.1.1411.1, probably on Monday.

We set the retention policy to 48 hours automatically when a new instance of A-Shell is started to keep users from messing up the settings. Some of the files that I deleted where dated back to sometime in 2013, so those files accumulated over a long period of time. Not sure how those files still existed, and that's not really a big deal. More important for the unique file check/overwrite to not error.

Thanks for fast response, and have a happy Memorial day. No need to rush to get this one fixed.

FYI, ATE 6.1.1411.1 is now available via the Check for Updates.