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:

SettingDefaultApplies toCommand
Incomplete payload retention24 hoursUploads that have started but not completed.config.filecache.incomplete.retentionhours
Completed payload retention24 hoursTemporary completed payloads. The period is based on last use where available, otherwise completion time.config.filecache.completed.retentionhours
Failed payload retention7 daysPayloads marked as failed.config.filecache.failed.retentiondays
Automatic cleanup enabledEnabledWhether Server runs automatic cleanup for eligible cached payloads.config.filecache.autocleanup.enabled
Automatic cleanup interval15 minutesHow 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:

SettingDefaultApplies toStudio locationCommandEffect timing
Maximum total cache size100 GBProjected upload cache size at upload admission; also reported in cache status. Use 0 for unlimited.Settings > Server > File Cacheconfig.filecache.maxsizegbRuntime setting. Applies to new upload admission checks.
Maximum active uploads2 uploadsConcurrent Studio-to-Server uploads. Use 0 for unlimited.Settings > Server > Uploadsconfig.uploads.maxactiveRuntime setting. Applies before a new upload is admitted.
Maximum single upload size10,240 MBOne Studio upload and one server-to-client file transfer payload. Use 0 for unlimited.Settings > Server > Uploads and Settings > Server > File Transfersconfig.uploads.maxsinglemegabytes; alias config.transfers.maxsinglemegabytesRuntime setting. Applies before accepting upload content and before queueing file transfers from payloads.
Maximum active upload bytes per user20,480 MBDeclared sizes of active uploads for the same administrator. Use 0 for unlimited.Settings > Server > Uploadsconfig.uploads.maxactivebytesperusermegabytesRuntime setting. Applies before a new upload is admitted.
Required free disk reserve1,024 MBFree disk space that must remain available for the upload cache. Use 0 to disable the reserve check.Settings > Server > Uploadsconfig.uploads.minimumfreediskreservemegabytesRuntime setting. Applies before a new upload is admitted and while chunks are written.
Upload rate limitUnlimited (0 Kbps)Configured Studio upload bandwidth limit.Settings > Server > Uploadsconfig.uploads.maxkbpsStored and displayed only. Changing this setting currently has no operational effect.
Maximum active transfers5 transfersConfigured global file transfer concurrency limit. Use 0 for unlimited.Settings > Server > File Transfersconfig.transfers.maxactiveStored and displayed only. Changing this setting currently has no operational effect.
Maximum active transfers per device1 transferConfigured per-device file transfer concurrency limit. Use 0 for unlimited.Settings > Server > File Transfersconfig.transfers.maxperdeviceStored and displayed only. Changing this setting currently has no operational effect.
Global transfer rate limitUnlimited (0 Kbps)Configured global server-to-client transfer bandwidth limit.Settings > Server > File Transfersconfig.transfers.maxglobalkbpsStored and displayed only. Changing this setting currently has no operational effect.
Per-device transfer rate limitUnlimited (0 Kbps)Configured per-device server-to-client transfer bandwidth limit.Settings > Server > File Transfersconfig.transfers.maxperdevicekbpsStored 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.