Saving documents through a temporary file in version 11

[DmitryDmitry]

After updating to PDF-XChange Editor version 11, I noticed that saving a document now works differently.

Instead of writing changes directly to the currently opened PDF file, the editor creates a new temporary file in the same directory, deletes the original file, and then renames the temporary file to the original filename.

Unfortunately, this behavior causes problems with my file synchronization software, Insync. It detects the deletion and replacement of the file instead of a normal modification, which disrupts synchronization.

Is it possible to restore the previous saving behavior, where changes were written directly to the existing file? Alternatively, could an option be added to the settings to choose between direct saving and the new temporary-file method?

[Daniel - PDF-XChange]

Hello, DmitryDmitry

thank you for the report, I was unaware such a change occurred, personally. I have reached out to the Dev team to see what can be done here, and how this can be rectified.

(Quick good news for you, it seems this was already caught and will be changing in the next release to resolve such issues)

Kind regards,

[DmitryDmitry]

Thank you for the quick response, that is great news!

[Daniel - PDF-XChange]

[DmitryDmitry]

Could you please release this build? I’d love to try it

[Daniel - PDF-XChange]

Hello, DmitryDmitry

It should hopefully be coming soon - our new pre-release testing process found a number of issues, so the build release was delayed a few times. As soon as those are confirmed resolved (hopefully in the next week or so) the next version should be available promptly!

Kind regards,

[TSon_BP]

We're experiencing the same issue with DFSR in Windows. The PDF files are being saved with the Temporary attribute; DFS sees this and doesn't replicate the file to our other offices until that attribute is removed.

[TSon_BP]

We're experiencing the same issue with DFSR in Windows. The PDF files are being saved with the Temporary attribute; DFS sees this and doesn't replicate the file to our other offices until that attribute is removed.

Adding a related finding for anyone running PDF-XChange Editor v11 against Windows file servers that use DFS Replication (DFSR).

Symptom: PDFs saved in v11 stop replicating to other DFSR members. No error, no backlog, the file just never shows up on the other servers.

Cause: after a save in v11 (tested on build 11.1.0), the PDF has the NTFS "Temporary" attribute set. DFS Replication skips files with the Temporary attribute by design, so the file is silently ignored. Repro: a PDF showed "Archive" before the save and "Archive, Temporary" after.

Check a single file (PowerShell):

Code: Select all

(Get-Item -LiteralPath 'C:\Path\To\File.pdf' -Force).Attributes

If the result includes "Temporary", the file is affected.

Clear it on a single file:

Code: Select all

$f = Get-Item -LiteralPath 'C:\Path\To\File.pdf' -Force
$f.Attributes = $f.Attributes -band -bnot [IO.FileAttributes]::Temporary

This removes only the Temporary flag and leaves every other attribute alone. DFSR sees the change and replicates the file.

Find all affected files under a folder (read-only):

Code: Select all

Get-ChildItem -LiteralPath 'D:\Shares\YourShare' -Recurse -File -Force -ErrorAction SilentlyContinue |
    Where-Object { $_.Attributes -band [IO.FileAttributes]::Temporary } |
    Select-Object FullName, LastWriteTime

Clear them all under a folder:

Code: Select all

Get-ChildItem -LiteralPath 'D:\Shares\YourShare' -Recurse -File -Force -ErrorAction SilentlyContinue |
    Where-Object { $_.Attributes -band [IO.FileAttributes]::Temporary } |
    ForEach-Object { $_.Attributes = $_.Attributes -band -bnot [IO.FileAttributes]::Temporary }

Notes:
- Run the "find" command first and review the list before clearing.
- Run these on the file server against the local path, not through a mapped drive, for speed.
- Some files are legitimately temporary (e.g. Office lock files starting with ~$, *.tmp). DFSR excludes those by default anyway, but you may want to filter them out.
- Every new save in v11 sets the flag again, so this is a cleanup, not a fix. We are running it on a schedule until the fixed build mentioned above is released.

Hoping the next release also stops the Temporary attribute from carrying over to the saved file, not just the delete/rename behavior.

[Sean - PDF-XChange]

Hi TSon_BP,

Thanks for the additional information. Have you updated to the new build, and can you confirm that the issue is resolved there?

Many thanks,

[Vasyl - PDF-XChange]

Hi TSon_BP.

This issue with the Temporary-attribute will be fixed soon, in the upcoming new release.
Thanks for the detailed report.

Cheers.

[DmitryDmitry]

I can confirm that I am still seeing the Temporary attribute issue on my system. Today I investigated a PDF that was not syncing and found that its attributes were Archive, Temporary. The file was readable and its permissions looked normal.

[Sean - PDF-XChange]

Hi Dmitry,

Can you please ensure you are using the current version of the software?

Kind regards,

[DmitryDmitry]

Yes, 11.1.0.0

[Daniel - PDF-XChange]

Hello, DmitryDmitry

Sorry for the confusion, the version Vasyl referred to which will be fixing this is 11.1.1, slated for release in the next week or so. Not the current version (11.1.0). Do keep an eye out for that release, but in the meantime I am sorry to say I do not know of a workaround.

Kind regards,