Behavior review for HTML5 File Manager with temporary files (e.g. *.part)

Dear Development Team,

We would like to submit the following request regarding the behavior of TSPlus Remote Access (HTML5 access) and its File Manager / webfile module when handling temporary files created by applications such as Okular, Word, or LibreOffice.

Environment

• Operating system: Windows Server 2019

• TSPlus: Remote Access with HTML5 access (web portal / File Manager)

• PDF viewer: Okular installed in the TSPlus session

• Each user has their own webfile folder, automatically created by TSPlus with the appropriate permissions.

Current behavior

1. A user generates a PDF report within their TSPlus session and chooses Save As in Okular.

2. The user saves the document directly into their webfile folder.

3. Okular first creates a temporary file with the $*.part$ extension, e.g. $report.pdf.part$.

4. The TSPlus HTML5 / File Manager module immediately detects this .part file in webfile and offers it to the browser as a downloadable file.

5. The browser rejects or blocks the download of the .part file because it is an unknown or potentially unsafe extension.

6. After that, Okular finishes generating the PDF and renames $report.pdf.part$ to $report.pdf$. The final $report.pdf$ file is correctly present in the webfile folder.

7. However, TSPlus has already triggered the download event for $report.pdf.part$ and does not trigger a new download event when $report.pdf$ appears.

8. As a consequence, the user only sees the blocked .part download and does not see any automatic download or offer for the final $report.pdf$, even though the file is present in the webfile directory.

We have observed similar behavior in the past with Word and LibreOffice, where temporary files are created before the final document. TSPlus seems to “hook” onto the temporary file rather than the final file.

Impact

• End users are confused because they see a blocked download for a .part file and assume the export failed.

• Users do not receive any download prompt for the final PDF, even though it exists in their webfile folder.

• This affects workflows where documents are generated and saved directly to webfile from applications that use temporary files.

What we would need from TSPlus

1. Technical verification and official confirmation

   • Confirmation from Development that this behavior is reproducible and understood:

     • Temporary files such as $*.part$ are detected by the HTML5 / File Manager module and offered for download.

     • When the temporary file is renamed to the final file (e.g. from $report.pdf.part$ to $report.pdf$), no new download event is triggered.

2. Configuration or change in behavior regarding temporary files
   Ideally, we would like the following behavior (or a configurable option):

   • The HTML5 File Manager / webfile should not list or offer for download files with certain extensions typically used for temporary or intermediate files, such as:

     • .part

     • (and possibly other extensions that you consider appropriate for temporary files from Office/LibreOffice/other applications)

   • Once the final file exists (e.g. $report.pdf$), the module should:

     • Either automatically offer this final file for download, or

     • At least ensure that this final file is clearly visible and downloadable from the File Manager, without having been “blocked” by the initial temporary file event.

3. Configuration options / documentation

   We would like to know:

   • Is this behavior (temporary file detection and download offer) already known and documented?

   • Is there any existing official configuration in TSPlus Remote Access to:

     • Ignore or hide files with specific extensions (e.g. .part) from the HTML5 File Manager and the automatic download mechanism?

   • If not, would it be possible to add:

     • A configuration setting (e.g. in an .ini file, registry, admin console, or portal configuration) where administrators can define a list of extensions to ignore in the File Manager and/or in the automatic download mechanism?

4. Recommended workaround or implementation guidance

   • If there is already a recommended workaround (update, patch, or existing setting), please let us know.

   • If the solution involves modifying the web portal’s JavaScript/HTML/CSS files:

     • Could you provide official guidance or an example on how to safely implement a filter that:

       • Prevents temporary files (e.g. *.part) from being offered to the browser, and

       • Ensures that the subsequent final file (e.g. *.pdf) is handled correctly (i.e. listed and, if applicable, offered for download)?

Summary of request

• We request an official review by the Development team of how the HTML5 File Manager module handles temporary files (e.g. .part created by Okular) in webfile.

• We request either:

  • An official configuration option to ignore specific extensions in the File Manager and automatic download events, and/or

  • A recommended solution (update/patch or code change in the portal) that ensures:

    • Temporary files are not offered to the browser, and

    • The final, renamed file is correctly made available to the user.

This behavior currently impacts users working with Okular and other applications that generate temporary files. An official confirmation and recommended solution would help us stabilize and improve our users’ workflow.

Thank you in advance for your time and assistance. We look forward to your feedback and any possible solution or enhancement you may provide.

Best regards,