Cache Directory – Again
Do not set the cache directory to c:, d: or any other important existing folder. Period.
IntraWeb in order to avoid consuming excessive amounts of memory uses the disk to cache files. These files and subdirectories are created both by IntraWeb and can be created by developer code as well.
These files need to be kept around for sometime, not simply until they have been initially served. The user can create files in these cache directories unknown to IntraWeb, and IntraWeb will clean these up for the user based on a time lapse.
Files in the cache directory can be created:
- By IntraWeb directly
- By user code, with no notification to IntraWeb
- Be left over from a previous instance after an upgrade
Tracking each and every file increases overhead and complexity unnecessarily. This is why IntraWeb takes complete control of the cache directory and will delete what it considers to be “old” or “stale” files or directories. The cache directory is 100% volatile storage.
The property is called CacheDir and not CacheDrive. By default the cache directory is created and managed by IntraWeb and no intervention is needed. However in some cases users may choose to use a network drive, location on an alternate volume, etc.
If left to default, CacheDir works without any issues or side effects. If you change it from the default, it will perform as designed.
However recently a user set the value to D: and complains that IntraWeb was at fault for deleting the contents of his D drive. It has created quite a flare up on the Chinese Delphi forums with users blaming Atozed for allowing a “violent bug” (Google translation).
IntraWeb did not randomly scour the drive. It did as it was told because the user overrode the default and specified D: for the CacheDir.
Would you set your temporary directory to C:? In fact ever notice how much garbage gets left in the temporary directories? Users need to run utilities such as CCleaner. In a server environment such slack quickly runs afoul, and is another reason for IntraWeb’s aggressive behavior in the cache directory.
If a user types:
deltree d: /Y
Is it a bug of deltree that it does what you asked? Should deltree prevent parameters of root being specified? Or should it do as it does currently and assume the user understands the command?
Is this a bug of format?
Why not prevent root access?
We looked at this solution before when one user changed it improperly to c:Windows. However some users do create dedicated volumes or mapped network drives in high capacity environments. So disallowing it is not an option, because it is a desired feature of some of our users, just as in some cases deltree d: /Y can be useful.
And if we prevent D:, where do we stop? This feature has been in IntraWeb for more than 5 years. With with tens ofthousands of users, this is only the second report of such a complaint.
Do we start to guess which directories should be restricted? What about c:My Vital Data? c:Britney Spears? c:Program FilesAdobeAcrobat Reader? Ok well, actually maybe the last one should be a default.