FileImporter drops Mission Package when filename is a bare UUID (no extension)

[Humble-Helper-96]

FileImporter drops Mission Package when filename is a bare UUID (no extension) — marker never rendered

Environment

Field	Value
TAKAware version	v1.8.1.262
TAKServer version	5.7-RELEASE8
Sender client	CloudTAK v13.4.0
Device	iPhone, iOS

Summary

When a marker with a photo attachment is sent from CloudTAK, TAKAware receives the b-f-t-r FileShare CoT, successfully downloads the Mission Package zip from TAKServer, then silently discards the file because the filename is a bare UUID with no extension. The marker is never rendered on the map. No error is shown to the user.

Steps to Reproduce

1. Connect TAKAware to a TAKServer instance
2. From CloudTAK (same TAKServer), create a new marker and attach a photo
3. Send/share the marker to the TAKAware client
4. Observe: marker does not appear on TAKAware map

Expected Behavior

Marker appears on map with photo attachment, matching the behavior of ATAK and iTAK receiving the same CoT.

Actual Behavior

Marker never appears. No error is shown to the user. Debug log shows the file is silently discarded inside FileImporter.

Debug Log — Key Lines

[StreamParser]: <event uid="64ac9fe2..." type="b-f-t-r">
  <fileshare filename="15eb6904-d988-4c3e-bd4e-b6b413306389"
    senderUrl="https://12.123.123.123:8443/Marti/sync/content?hash=090d95..."
    sha256="090d95..." sizeInBytes="27529"/>
</event>
[StreamParser]: File transfer request b-f-t-r received. Processing.
[ServerViewModel]: Making request to https://...8443/Marti/sync/content?hash=090d95...
[ServerViewModelDelegate]: Retrying with local truststore
[ServerViewModelDelegate]: Using client identity
[ServerViewModel]: Successfully received data from the request, ignoring Mime Types
[FileImporter]: Initializing
[FileImporter]: Starting file processing
[FileImporter]: Unknown file type 15eb6904-d988-4c3e-bd4e-b6b413306389 received. Not processing further.
[COTDataSaveCoordinator]: Save requested but no changes found

The same failure pattern was observed twice in the same session with different UUID filenames.

Root Cause Analysis

CloudTAK names the Mission Package file with a bare UUID hash (no .zip or .dp extension). FileImporter appears to determine file type from the filename extension only. When no extension is present it logs "Unknown file type" and aborts without processing the file.

Note: ServerViewModel logs "ignoring Mime Types" on the successful download response, suggesting the HTTP Content-Type header is also not being used for type detection.

Suggested Fix

When the filename has no recognizable extension, fall back to file magic byte detection (PK\x03\x04 = zip/Mission Package) or trust the HTTP Content-Type: application/zip header returned by TAKServer. ATAK and iTAK both handle this case correctly on the same CoT.

Additional Notes

• Plain CoT markers (no attachment) are received and rendered correctly on the same connection
• The TLS download itself succeeds — this is not a certificate or network issue
• ATAK (Android, v5.7.0.4) and iTAK (iOS) both receive the same attachment markers without issue
• Full debug log attached