Temporary files are not deleted. - Java.io.FilePermission Error

[larsS]

Hello,

when I edit an XSLT or XQUERY file in XSLT/XQuery debug mode, or in general, "oxy_tmp_*****" files are created in the same folder.

This error is constantly displayed:

Code: Select all

java.security.AccessControlException: access denied ("java.io.FilePermission" "C:\Users\***\oxy_tmpET5306498678649739040.xsl" "delete")
	at java.security.AccessControlContext.checkPermission(Unknown Source)
	at java.security.AccessController.checkPermission(Unknown Source)
	at java.lang.SecurityManager.checkPermission(Unknown Source)
	at ro.sync.security.manager.SandboxSecurityManager.checkPermissionInternal(SandboxSecurityManager.java:305)
	at ro.sync.security.manager.SandboxSecurityManager.checkPermission(SandboxSecurityManager.java:256)
	at java.lang.SecurityManager.checkDelete(Unknown Source)
	at java.io.File.deleteOnExit(Unknown Source)
	at ro.sync.xml.transformer.ob.<init>(Unknown Source)
	at ro.sync.xml.transformer.eb.<init>(Unknown Source)
	at ro.sync.xml.transformer.c.x(Unknown Source)
	at ro.sync.xml.transformer.c.lb(Unknown Source)
	at ro.sync.exml.validate.scanners.g.r(Unknown Source)
	at ro.sync.exml.validate.e$1.b(Unknown Source)
	at ro.sync.exml.validate.e$1.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at ro.sync.security.Sandbox.runInContext(Sandbox.java:475)
	at ro.sync.security.Sandbox.runWithPerms(Sandbox.java:340)
	at ro.sync.exml.validate.e$2$1$1.b(Unknown Source)
	at ro.sync.exml.validate.e$2$1$1.run(Unknown Source)
	at ro.sync.security.SandboxCore.runWithConfirmation(SandboxCore.java:258)
	at ro.sync.security.ThreadsSandbox.runWithThreadConfirmation(ThreadsSandbox.java:76)
	at ro.sync.security.Sandbox.runWithThreadConfirmation(Sandbox.java:428)
	at ro.sync.exml.validate.e$2$1.b(Unknown Source)
	at ro.sync.exml.validate.e$2$1.run(Unknown Source)
	at ro.sync.security.SandboxCore.runWithConfirmation(SandboxCore.java:258)
	at ro.sync.security.FilesSandbox.runWithWriteConfirmation(FilesSandbox.java:75)
	at ro.sync.security.Sandbox.runWithWriteConfirmation(Sandbox.java:413)
	at ro.sync.exml.validate.e$2.b(Unknown Source)
	at ro.sync.exml.validate.e$2.run(Unknown Source)
	at ro.sync.security.SandboxCore.runWithConfirmation(SandboxCore.java:258)
	at ro.sync.security.ConnectionsSandbox.runWithConnectConfirmation(ConnectionsSandbox.java:263)
	at ro.sync.security.Sandbox.runWithConnectConfirmation(Sandbox.java:355)
	at ro.sync.exml.validate.e.d(Unknown Source)
	at ro.sync.exml.validate.scanners.q.d(Unknown Source)
	at ro.sync.exml.editor.validate.r.mwe(Unknown Source)
	at ro.sync.exml.editor.validate.r.kwe(Unknown Source)
	at ro.sync.exml.editor.validate.r.hwe(Unknown Source)
	at ro.sync.exml.editor.validate.r.nve(Unknown Source)
	at ro.sync.exml.editor.ld.e(Unknown Source)
	at ro.sync.exml.editor.ld$1.xgk(Unknown Source)
	at ro.sync.ui.application.lb.run(Unknown Source)

Oxygen XML Editor 23.1 build 2021040908
Program: Saxon EE-9.9.1.7

Please help, it is very uncomfortable.

sincerely,
L

[adrian]

Hello,

Note the Oxygen temporary folder where the temporary files are kept, OxygenXMLTemp. There may be a Windows permissions issue with this folder and that's why Oxygen can't delete the files. e.g. "C:\Users\***\OxygenXMLTemp\oxy_tmpET5306498678649739040.xsl"
To fix this:
1. Quit Oxygen.
2. Navigate to the user profile Temporary folder, C:\Users\<username>\AppData\Local\Temp. To get there fast, open File Explorer, type in the Address bar %TEMP% and press Enter.
3. Delete the folder "OxygenXMLTemp".
4. Start Oxygen.

Regards,
Adrian

[larsS]

Hello Adrian,

thank you for your suggestion.

Unfortunately, it didn't have any effects on the error.
I also suspect that it is an access problem with the MS Windows permissions. Probably the write protection of MS Windows.
But other temporary files, such as the expandLayout files, are written without any problems or error messages.
Since I don't have admin rights to change any permissions on folders, I'll have to test this with the administrator.

I just thought maybe the case is known or I could have set FilePermissions.

[adrian]

Hi,

Please export your global options (menu > Options > Export Global Options) and send them to our support email address, support@oxygenxml.com, so we can investigate if there's anything in the configuration that may be triggering this.

If the error keeps popping up and is interrupting you, you could disable the Oxygen security manager that triggers the error when checking for the FilePermission.

For starting Oxygen via the oxygen23.1.exe launcher (or start menu/desktop shortcut), the security manager can be disabled by creating a file named custom_oxygen.vmoptions, with the argument:

Code: Select all

-Dcom.oxygenxml.disable.security=true

Copy this file custom_oxygen.vmoptions to the Oxygen folder (next to the oxygen23.1.exe launcher) and restart Oxygen. This should bypass the FilePermission check.

Regards,
Adrian

[larsS]

Hello Adrian,

I will send the E-Mail with the Export from Global Options ASAP.

Disabling the security manager in the custom_oxygen.vmoptions worked.
But I think that can only be an in-between solution.

Thank you for your efforts and assistance.

[alex_jitianu]

Hello,

For security reasons, Oxygen runs certain operations that run without the user's knowledge, like the automatic validation, in a sandbox with limited permissions. The issue is related with the fact that you are using a custom validation engine, named Saxon-EE 9.7, which is an external Saxon 9.7 processor. For such custom engines, Oxygen tries to create a temporary file and, because of the limited permissions, it fails.
I will add an issue on our side to give additional permissions on this step. Until we release the fix, you can either switch to the built-in Saxon for validation or keep the security features disabled.

Best regards,
Alex

[ycreech]

I am also having this error message with Oxygen 22.1 and 24.1 Author/Editor. We use a custom Scenario for the creation of the pdf from a custom scenario to create the file with the .fo extention. My error message is as follows:
"Cannot delete temporary FO file:" \\sp.....{filename}.fo_fo. If I click on More Details, I get the following
java.io.IOException: Cannot delete temporary FO file: \\sp...{filename}.fo_fo
at ro.sync.exml.editor.xmleditor.hc.qih(Unknown Source)
at ro.sync.exml.editor.xmleditor.hc.thh(Unknown Source)
at ro.sync.exml.editor.xmleditor.hc.dhh(Unknown Source)
at ro.sync.exml.editor.xmleditor.hc.tih(Unknown Source)
at ro.sync.exml.editor.xmleditor.hc.wgh(Unknown Source)
at ro.sync.exml.editor.xmleditor.hc$4.lre(Unknown Source)
at ro.sync.ui.application.lb.run(Unknown Source)

I have removed most of the path above for privacy and used the ...{filename} is its place. This problem started accruing after workstations where upgraded to the KB5010415 Microsoft patch (Feb. I have rolled back the update but still get the "cannot delete" error.
Any assistance you can give would be greatly appreciated.

[adrian]

Hi,

From what you're showing from the path "\\sp.....{filename}.fo_fo" I can deduce this is a network UNC path. \\serverName\shareName
Please check (or have an admin check for you) the permissions for the network share and network folder where the temporary file is created.
It is possible to have file creation and write permissions without having file delete permissions. This could be the case here.

Regards,
Adrian

[ycreech]

First of all, Thank you for your quick response. This may not be the correct topic to post this because of the differences in the location of the temporary files being stored in SharePoint, and if there is a better place to post, please let me know. Let me expand on my scenario. The company I work for has been doing this SAME process for about 7 years and have not had an issue until now. We have in the past been able to publish from various workstations logged in as different users going to same SharePoint site. Our process, reads the xml and xslt, renders an fo and then converts to pdf, all files reside on a SharePoint 2016 server, no permissions have changed. Please find below the screen shot of the error from Results on the Transformation problems tab.

Results.png

Message.png

when clicking on the More details... the following message shows, I have removed path and replaced with {FileName}
java.io.IOException: Cannot delete temporary FO file: \\sp....){FileName}.fo_fo
at ro.sync.exml.editor.xmleditor.hc.qih(Unknown Source)
at ro.sync.exml.editor.xmleditor.hc.thh(Unknown Source)
at ro.sync.exml.editor.xmleditor.hc.dhh(Unknown Source)
at ro.sync.exml.editor.xmleditor.hc.tih(Unknown Source)
at ro.sync.exml.editor.xmleditor.hc.wgh(Unknown Source)
at ro.sync.exml.editor.xmleditor.hc$4.lre(Unknown Source)
at ro.sync.ui.application.lb.run(Unknown Source)

Please let me know if more information is needed.

[adrian]

Hi,

I suspected it was SharePoint, but this doesn't change much, other than that the permissions are in the SharePoint site.
Can you manually create a file of a similar name (as the3 temporary one) there in the same folder, and then delete it?

Regards,
Adrian

[ycreech]

Yes, I can manually create a file with the extension .fo_fo and delete it from the SharePoint site. I am unclear as to when Oxygen XML creates the .fo_fo file to use in the transformation from xml/xslt to fo to pdf. We have 2 custom transformation scenario's that run back to back, first the FO and the PDF. I have attached screenshots of their configuration.
Hope this information is useful, any assistance you can give is greatly appreciated.

[adrian]

Hi,

Make sure Oxygen is not being run in compatibility mode or with admin rights (check Properties for Oxygen launcher/shortcut > Compatibility tab).

I am unclear as to when Oxygen XML creates the .fo_fo file to use in the transformation from xml/xslt to fo to pdf.

Normally that file is only created for a transformation whose XSLT result is used as input for the FO Processor. It's that intermediary result of the XSLT transformation that is saved as a temporary file with the suffix _fo. I see your scenario actually uses the XML URL as input for the FO processor, so there is no XSLT transformation in this scenario (PDF: ...).
I think this happens because the scenario is of type XSLT transformation. Check in the "Configure Transformation Scenario(s)" dialog. Look at the Type column.
A scenario for which the XSLT transformation is treated as optional is of type "XML Transformation with XSLT" (not the same thing as "XSLT transformation" with regard to inputs). So creating a scenario of type "XML Transformation with XSLT" that uses the "XML URL as input" for the FO Processor should no longer create that temporary file.

Regards,
Adrian

[ycreech]

Thank you for your patience, I recreate the scenario as you suggested, but it did not change anything, We have found that if we go into Oxygen XML, Options, Preferences, XML, XSLT-XQuery and set the check box "Create transformation files in system temporary directory", the publication works. Now, that looks to me like it wants to use the user's/pc's temporary location and we don't want this information being written to local pc's but rather to the server location that it has written to for over 7 years without issue until now. Any help you can give is greatly appreciated.

[adrian]

Hi,

We have found that if we go into Oxygen XML, Options, Preferences, XML, XSLT-XQuery and set the check box "Create transformation files in system temporary directory", the publication works.

Actually that is the correct solution to avoid having the temporary files created in the input directory (server location), which is the trigger for the issue here. I have overlooked this option, but it is very useful in this case.

Now, that looks to me like it wants to use the user's/pc's temporary location and we don't want this information being written to local pc's but rather to the server location that it has written to for over 7 years without issue until now.

Having temporary files on the server location isn't really an advantage.
Also, I hope you realize that there are other temporary files that are stored in the local system temporary directory. e.g. If you open a very large file, Oxygen creates a local copy of that file in the system temporary directory. There are other cases as well.

If there are multiple versions of Oxygen that suddenly started to show the issue at the same time after 7 years, it's not a regression in Oxygen. I believe you can't fix it from Oxygen, if it was triggered by a server side change. You can only avoid it from Oxygen, and that's what that option is actually for.
My best guess is there was either:
* a server side update (SharePoint site) that somehow changed file permissions, or
* an actual file permissions (or role) change for the SharePoint user account

Yes, I can manually create a file with the extension .fo_fo and delete it from the SharePoint site

1. Have you tried this from File Explorer via the same \\sp...\DavWWWRoot network share?

2. Can you find there (on the network share) the temporary files that Oxygen mentions it cannot delete (after a transformation)? Sometimes it can't delete a file because it's not there in the first place, so it's not a deletion permission error, but a missing file error.

3. Do you get an elevation confirmation when you try to delete the file from File Explorer?
e.g. a dialog with the message "You'll need to provide administrator permission to delete this file (Continue/Skip/Cancel)"?

Regards,
Adrian

[ycreech]

Hello,
Yes, I can maneuver to the folder in file explorer and delete the file without giving any elevated permissions.