Server File Cache
The Server File Cache stores uploaded payloads used by Lanview.
It supports file transfer and related features where Studio uploads content before it is sent to devices.
The cache is not a document repository and should not be used as long-term file storage.
What the cache stores
The cache can store uploaded payloads used by Lanview features, including File Transfer and package-related operations.
Manage cache content through Lanview Studio, Server settings or supported console commands. Do not modify cache files directly on disk.
Retention and cleanup
Lanview can apply separate retention periods to:
- incomplete payloads
- completed payloads
- failed payloads
Automatic cleanup can also be enabled and given a cleanup interval.
Default retention settings are:
| Setting | Default | Applies to | Command |
|---|---|---|---|
| Incomplete payload retention | 24 hours | Uploads that have started but not completed. | config.filecache.incomplete.retentionhours |
| Completed payload retention | 24 hours | Temporary completed payloads. The period is based on last use where available, otherwise completion time. | config.filecache.completed.retentionhours |
| Failed payload retention | 7 days | Payloads marked as failed. | config.filecache.failed.retentiondays |
| Automatic cleanup enabled | Enabled | Whether Server runs automatic cleanup for eligible cached payloads. | config.filecache.autocleanup.enabled |
| Automatic cleanup interval | 15 minutes | How often Server checks for eligible cached payloads while automatic cleanup is enabled. Runtime changes apply on the next maintenance wait cycle. | config.filecache.autocleanup.intervalminutes |
The current values are shown in Settings > Server > File Cache. In the current Studio build these values are shown as Server config metadata rather than editable fields. Change them with the corresponding config.filecache.* commands or supported startup configuration.
Cleanup removes eligible cached payloads according to the configured rules. It is not a secure deletion function.
Upload and cache limits
The file cache works alongside hard limits that protect Server storage and network capacity.
These can include:
- maximum cache size
- maximum active uploads
- maximum single upload size
- maximum active upload bytes
- required free disk reserve
- transfer rate limits
Confirmed defaults are:
| Setting | Default | Applies to | Studio location | Command | Effect timing |
|---|---|---|---|---|---|
| Maximum total cache size | 100 GB | Projected upload cache size at upload admission; also reported in cache status. Use 0 for unlimited. | Settings > Server > File Cache | config.filecache.maxsizegb | Runtime setting. Applies to new upload admission checks. |
| Maximum active uploads | 2 uploads | Concurrent Studio-to-Server uploads. Use 0 for unlimited. | Settings > Server > Uploads | config.uploads.maxactive | Runtime setting. Applies before a new upload is admitted. |
| Maximum single upload size | 10,240 MB | One Studio upload and one server-to-client file transfer payload. Use 0 for unlimited. | Settings > Server > Uploads and Settings > Server > File Transfers | config.uploads.maxsinglemegabytes; alias config.transfers.maxsinglemegabytes | Runtime setting. Applies before accepting upload content and before queueing file transfers from payloads. |
| Maximum active upload bytes per user | 20,480 MB | Declared sizes of active uploads for the same administrator. Use 0 for unlimited. | Settings > Server > Uploads | config.uploads.maxactivebytesperusermegabytes | Runtime setting. Applies before a new upload is admitted. |
| Required free disk reserve | 1,024 MB | Free disk space that must remain available for the upload cache. Use 0 to disable the reserve check. | Settings > Server > Uploads | config.uploads.minimumfreediskreservemegabytes | Runtime setting. Applies before a new upload is admitted and while chunks are written. |
| Upload rate limit | Unlimited (0 Kbps) | Configured Studio upload bandwidth limit. | Settings > Server > Uploads | config.uploads.maxkbps | Stored and displayed only. Changing this setting currently has no operational effect. |
| Maximum active transfers | 5 transfers | Configured global file transfer concurrency limit. Use 0 for unlimited. | Settings > Server > File Transfers | config.transfers.maxactive | Stored and displayed only. Changing this setting currently has no operational effect. |
| Maximum active transfers per device | 1 transfer | Configured per-device file transfer concurrency limit. Use 0 for unlimited. | Settings > Server > File Transfers | config.transfers.maxperdevice | Stored and displayed only. Changing this setting currently has no operational effect. |
| Global transfer rate limit | Unlimited (0 Kbps) | Configured global server-to-client transfer bandwidth limit. | Settings > Server > File Transfers | config.transfers.maxglobalkbps | Stored and displayed only. Changing this setting currently has no operational effect. |
| Per-device transfer rate limit | Unlimited (0 Kbps) | Configured per-device server-to-client transfer bandwidth limit. | Settings > Server > File Transfers | config.transfers.maxperdevicekbps | Stored and displayed only. Changing this setting currently has no operational effect. |
The current Studio build shows these values in Settings > Server > File Cache, Uploads and File Transfers as Server config metadata. It does not provide edit fields for these limit settings. Change confirmed settings with the listed config.filecache., config.uploads. and config.transfers.* commands or supported startup configuration.
Increase limits only after checking available Server storage, expected file sizes and the number of simultaneous transfers.
Where to manage cached files
Open Settings > Server > File Cache in Lanview Studio.
Where the current build exposes cache management, authorised administrators can view cached payloads, inspect metadata, upload new content and remove entries.
Permissions
Use the current permission catalog to confirm file cache management permissions.
Console usage may require server.console. Sending cached payloads to devices also requires the relevant file transfer and target permissions.
Audit behaviour
Lanview audits cache-related activity.
Audit records can include:
- upload completed
- file cache cleared
- file cleanup
Audit summaries should not expose payload contents.
Common problems
An upload is rejected
Check the maximum single upload size, active upload count, total active upload bytes and required free disk reserve.
If the file is expected and the Server has sufficient capacity, an authorised administrator can adjust the relevant hard limit. Avoid increasing several limits at once; change the setting that caused the rejection and retest.
The cache is full
Review cache usage, retention periods and automatic cleanup.
Remove payloads that are no longer needed through Studio or a supported cache command. If the expected workload genuinely exceeds the current cache size, increase the maximum cache size only after confirming that sufficient disk space will remain available.
A file disappears from the cache
Cached files are subject to retention and cleanup. The cache is not permanent storage.
Where supported, pin payloads that must remain available longer than the normal retention period.
Cleanup does not free enough space
Check for:
- active uploads that are not eligible for cleanup
- pinned payloads
- completed or failed payloads still inside their retention period
- automatic cleanup being disabled
- a cleanup interval that has not yet elapsed
- the maximum cache size being too low for normal activity
Use a manual cleanup through Studio or a supported command where appropriate. Then review the hard limits rather than repeatedly clearing files needed by active work.
Console commands
Related console commands include:
config.filecache.autocleanup.enabled
config.filecache.autocleanup.intervalminutes
file.cache.list
file.cache.show
file.cache.clear
file.cache.pin
file.cache.unpin
Guidance
Size the cache for the file transfer and package activity the organisation actually uses.
Review retention and hard limits together. Very long retention periods combined with a small cache can cause avoidable upload failures, while unnecessarily large limits can consume Server storage quickly.