One to ponder... Could the ATE Cache folder be cleared out only when the last ATE is closed?
I noticed some user logs in and the cache is populated.. then they login in a 2nd ATE and do something and close it straight after ... when the 1st ATE tries to print some GDI form the cache is empty....

Interesting point. Just out of curiosity what sorts of logs would you be sharing between 2 independent ATE sessions?

Also, could just use permacache right?

Yes i have pondered on maybe best to use the "permacache" and they just get updated rather than cleared ... That would save any ATE tweaks too.
If you mean log files, I dont really have any logs on the clients they all on the server side.

Good suggestion about delaying the clearing out of the ATECACHE directory until the last instance exits. That seems straightforward and reasonable, although it also raises a possible question of whether it would make as much sense to further subdivide the ATECACHE directory into instance-specific subdirectories. I guess it comes down to whether there is a risk of two server programs sending conflicting versions of the same file to the client. That seems somewhat doubtful. I would guess that most, of not all, of the files sent from the server to ATECACHE are things like images or subroutines, which could easily be shared between ATE sessions.

After a little more thinking sparked off by Frank maybe I will just place them in %atepermcache% as I cant think of a reason they cant stay there as long as XCALL ATESYC updates if there is a newer version, the temporary cache was just certain they were the latest from the server..

Crossed posts... Well if its easy to clear on the last ATE close down or even instance-specific sub-directories im up for that, if a pain in the a*** to change then I will try %atepermcache%

It would be relatively easy to delay the clear until the last instance exited. I probably can't do it today, but could commit to implementing it over the weekend.

The instance-specific sub-folder idea I think requires more time to think through the potential unintended consequences.

OK a simple clear be good Thanks, No hurry .. Much appreciated.

{LIKE} Button Pressed...

I've often thought it would be nice to have a number of days sub directory cache. This would be more in-line with how browser caching works with cache headers.

i.e. %ATECACHE%\cache60, %ATECACHE%\cache5

This would like somewhere between permanent cache and instant cache deletion.

Hmmm.... I had a feeling we were opening the door to another dimension...
I take it you're imagining that the server side could decide on the cache duration by specifying an appropriately named subdirectory?

Maybe it could use the current ashell jobname as the subdir name...

That was the thought.

It's not necessary, just figured if you're making a change might as well bring it up.

The idea of variable-length cache duration is going to require more thought. Given that the only explicit cache references in an application are likely to be to the ATEPERMCACHE, it really seems like the duration option would apply to that context, reducing the lifetime of the ATEPERMCACHE (or of its variations) rather than increasing the lifetime of the ATECACHE. What's not clear to me is the kind of reasoning an application would use to decide to set the lifetime of some, say, client-side icons, to, say, 30 days instead of unlimited. And would that reasoning work differently for each file, or just be a general rule. In the latter case, it would make more sense to implement an option to set the duration of the ATEPERMCACHE (similar to the way the APEX retention policy works, except that option is generally configured by the ATE user rather than by the application).

So for now, I've just modified the logic for clearing the ATECACHE so that it only clears when the last instance of ATE (or, for that matter, A-Shell/Windows), exits. (It may not make a log of logical sense to bundle A-Shell/Windows with the ATE instance count, but it's simpler this way since they both use the same ashw32.exe executable, and as a practical matter in the field, it probably makes no difference.)

Here's a link to the updated version 6.5.1664.4 ...

ash-6.5.1664.4-w32-upd.zip

Thanks, tested and ATECACHE as per design now just clears when my last ATE instance closes down.

{Like}

I'm going to preface this with as I stated before "It's not necessary, just figured if you're making a change might as well bring it up." Here are 2 use cases where variable day caches would be nice.

- One of our customers has an order book they print every six months that contains several hundred //XTEXT files. We currently sync this to a directory C:\ATE\gdiaux\xtext\ using AG_FTPSYNC, this limits the files to only being synced to the PC once while they're printing. We thought about implementing a cache days/time mechanism when we originally wrote this. We decided that the size of the files was small enough that we weren't going to worry about it at the time and come back to this if it becomes a problem.

- When a user is viewing an item description they can optionally view the images. We copy the files to the PC; rather than using Samba. We used to use samba for this, but it meant that the images were only available to when users were on-site (or perhaps VPN) connected to the LAN. There are also security issues related to samba being available, with the possibility that crypto-malware could affect the shares.

Both of these cases would benefit from some cleanup of these files.

The main concern about allowing the host to create arbitrary CACHE## directories (where ## indicated the cache life in days) would be added complexity of having to do a general directory scan to locate the applicable subdirectories (as opposed the existing search path which is static.) And there there's the potential for inadvertently growing an entire forest of subdirectories with different lifetimes. But the former isn't really that big of a deal, and the latter could be minimized by auto-deleting any such directory when the last file was deleted.

There would also be some confusion over how these directories were defined/located and documented As it stands the Temporary (%ATECACHE%) and permanent (%ATEPERMCACHE%) directory locations are defined in the ATE connection configuration (although probably virtually all of them use the default of %MIAME%\cache and %MIAME%\permcache). As long as it seems reasonable to use build this new class of cache folders on the existing ATECACHE directory name (appending ###), that would avoid having to add an additional configuration parameter.

So I guess you've convinced me. Not sure when it will be implemented, but it's on the list.