Obstacle backing up application installer with FreeFileSync

DIVERSE · 2024-04-22T14:18:19+00:00

There was an error rendering this rich post.

Today I installed FreeFileSync 13.5 ("FFS") on my Windows 10 x64 laptop. (Finally upgraded from Windows 8.1!). Although I've used it before on another machine, I thought I'd start out with a trial run backing up the contents of my "Temp" folder, where — amongst other things — I save application installers. Nominally that's supposed to be temporary, but I tend to seldom delete them….

Bitdefender Internet Security (build 27.0.35.147) ("BIS") flashed up a message about PrimoPDF being a potentially unwanted application. These days I mainly use PDF-XChange Editor from Tracker Software, but I am happy enough for PrimoPDF to remain installed as an alternative, so I clicked "Ignore" (or words to that effect).

Subsequently I discovered that FFS was also showing an "Error" notification about PrimoPDF. Effectively, it was unable to backup the installer for PrimoPDF! (FWIW, this is the installer for version 5.1.0.2 of PrimoPDF, "international".) It SEEMS that what happens is that FFS initiated copying of the file from my local SSD to the external USB HDD with a temporary extension (a bit like some internet file downloading); once the copying was complete, BIS recognised the file as an application installer, and FFS recognised that the transfer was finished; the conflict then arose as BIS blocked FFS from renaming the copied file with the extension of the original file to complete the backup process.

When I clicked "Retry" in FFS, another notification was generated from BIS (the lower message above), at which point my brain joined the dots, and I clicked "View details" ….

For more context, my Temp folder has 4527 files (46.4 GB). The majority (by number and by size) are installers, or related stuff. Everything else was reported by FFS as copying without problem.

Has anyone else encountered this kind of issue?

Any theories on why PrimoPDF was singled out? Something about "Bundler.CZO" is mentioned in the log. (Information online inconsistent about whether this kind of thing is a heuristic rule, or a specific signature.)
Is it fair enough that BIS did this, or was it overstepping the mark?

Is there a convenient & sensible fix or workaround for this?
I'm imagining that a workaround would have to be adding an exception to BIS for either FFS or PrimoPDF.

Find more posts tagged with

Comments

DIVERSE

As a follow-up, I thought I would submit the 'offending' file to the VirusTotal website.

Imagine my surprise to find that the original file has disappeared. Disappeared from my local HDD.

No sign of it in the (intuitive) location indicated by the paths shown in the screenshots.
No sign of it in the Recycle bin.
No sign that BIS did anything to the original file among the BIS Notifications.

FFS is still reporting that the original file is yet to be backed up, and has a size of 7,549,704 bytes, although perhaps that could be still appearing if FFS hasn't refreshed its listing yet.

If BIS has deleted the file without notifying me, without asking me, and without providing a means to reverse the deletion, then BIS has failed.
I was not informed that the file would be deleted, I did not agree to delete the file, and — so far — I can't find a way to get it back.

I suppose it could also be a FFS bug, although I configured all of the options in FFS so that (a) no deletions would occur during the backup process and (b) any files deleted during the backup process [should be none] would be moved to an archive folder.

UPDATE 1: I have now confirmed that when I refresh the file listing in FFS, the original file no longer shows up there either. That means the deletion must have happened after I generated the initial file listing in FFS this evening, shortly before I started the backup itself.

UPDATE 2: And note that PrimoPDF remains installed on my computer. It is only the installer that has vanished!

Note:

(i) I've never encountered this problem when backing up with SyncToy (version 2.1), which is what I was using for many years with the Windows 8.1 system;

(ii) the problem didn't arise with Macrium Reflect;

(iii) although I must have that file saved on a previous backup to a different external HDD (made with SyncToy or Macrium Reflect), I'm concerned if I access it now BIS might decide to delete that instance too (not that the file is vital to me, but the concept is disturbing).

Meanwhile, this appears to be the same version of PrimoPDF still available online through Softonic (although I can't vouch that it's exactly the same installer).

DIVERSE

FWIW, I have downloaded the PrimoPDF installer from Softonic.

VirusTotal reports it as clean.

BIS on my system (with heuristic checking enabled) also reports that it is clean.

FFS has successfully copied the PrimoPDF installer file that I got from Softonic to the portable HDD. No notifications from BIS. The (new) original copy of the file remains present.

Indications were that what I newly downloaded from Softonic matched the previous file: version 5.0.1.2, "international". However, belatedly I check the file size, and it is only 7,274,960 bytes. So apparently it's not quite the same file after all.

DIVERSE

OK, I think I may have found a source for the installer that I originally had: through SourceForge. File size is given as 7.6 MB.
https://sourceforge.net/projects/primopdf/files/

SourceForge itself flags that the executable installer "may be infected with malware".

SPOILER: actually, it turns out that this is not the same file that I originally had.

While attempting to download the file (without running it!) BIS brought up the following convoluted timeline, which apparently relates to Opera storing a copy of the contentious file in its cache folder. [Apparently I clicked a link in FFS which initially triggered the launching of Opera; not important, just a coincidence.]

Apparently BIS intercepted this so that the action of saving to my specified local folder did not occur.

On the positive side, at least I was notified about this by BIS! Furthermore, I'm given the option to restore the file.

Upon restoring the cache file I can confirm that its size is 7,627,728 bytes. VirusTotal reports many threat detections.

Based on the different size, it's evidently a different file, and it cannot reproduce the notifications generated by FFS and BIS on the first occasion.

Nevertheless, it's seeming more likely to me that BIS silently & unrecoverably deleted the original installer on the first occasion.

DIVERSE

Checking the browser I would have been using at the time the original PrimoPDF installer file was downloaded, it appears that it most likely came from either primopdf.com or cnet.com (both accessed on 2017-06-23). Neither of these are still accessible:

http://www.primopdf.com/ (now redirects to gonitro.com)
http://download.cnet.com/PrimoPDF/3000-10743_4-10264577.html?part=dl-10264577&subj=dl&tag=button (no longer available)

OK, so that's a dead end. Nevertheless, there are still numerous other sources online to download PrimoPDF. Spoiler: I found the same file online that had been silently removed from my computer yesterday.

There are four different files I've found, all described as PrimoPDF version 5.1.0.2 "International":

Bare installer (clean) 7,274,960 bytes 6.94 MB from Anturis, Digital Trends, Download.it, FileHippo, LO4D, MajorGeeks, Softonic, Softpedia
OldVersion.com (OpenCandy) 7,458,096 bytes 7.11 MB
DIVERSE's laptop (Bundler.CZO/OpenCandy) 7,549,704 bytes 7.20 MB also from FindMySoft
SourceForge (Graftor/ClipBanker) 7,627,728 bytes 7.27 MB

Interestingly, BIS detects no threat from the 7.11 MB file, even though it also has OpenCandy. Arguably the use of OpenCandy in bundling PrimoPDF is not a serious threat. (Graftor/Clipbanker might possibly be more of a concern, but that didn't relate to the file that I originally had on my system.)

I also note that Bundler.CZO was detected by BitDefender, but not BitDefenderTheta.

DIVERSE

Statistics for the 7.20 MB file c/o 7-Zip:

Size: 7549704 bytes (7372 KiB)
CRC32: 01D76399
CRC64: 819955ADDCB2EA67
SHA256: 600408029D622447C7BAB40A0DE9C67B35037FA1C0FA69B7F24E06F8F75EF181
SHA1: BD3D451BFB56B02EDD3D2D1FEA10E29EC94F1A8C
BLAKE2sp: 296AB7A4F3B5CBEE010818FF49488EAD535613EDBF9AAB1B37BF63CE1FA0C28C

DIVERSE

Still unable to completely reproduce the original issue.

I can reproduce the same warning in FFS.

After hitting "Retry" a couple of times (with the same result), eventually some on-screen notifications are shown from BIS — rather delayed, I would say.

Furthermore, the notification shown in the GUI (below) is misleading: it implies that the file exists on the external HDD (not yet quarantined), but actually it's been deleted (or quarantined???)!

Note: if I don't hit "Retry" within FFS (just wait for ~3 minutes), then BIS doesn't produce any notifications! Not on screen, nor in the list shown in the BIS GUI.

Critically, the file on C: was not deleted in this trial….

Tried again with an EXE extension — same result as in the trial with "dummy" as the extension.

Maybe the trial is unable to reproduce the original behaviour because I am now forced to explicitly ask BIS to restore the file from quarantine in order to (i) rescue it from deletion in Opera's cache, and (ii) rescue it from deletion when moving from Opera's cache to a directory under my Temp folder.

DIVERSE

I have found what looks to be the general setting in BIS, namely "Scan potentially unwanted applications".

I temporarily disabled that feature, renamed the executable to "PrimoPDF_LollyshopTest.exe", and then re-enabled the feature. That way the 'new' file can't have been recorded by BIS as having been recovered from the Quarantine.

Now I run the trial with FFS once again.

This time FFS is not merely blocked from creating/renaming the file on the external HDD, but the file on my local SSD has been deleted. (So it appears that my theory about BIS remembering which files a user has recovered from Quarantine may be correct.)

The other key differences from the very first occasion are that this time (i) I am explicitly notified about the file deletion and (ii) there is an option to 'undo' BIS's action.

DIVERSE

OK, I have noticed that I might have overlooked something.

In my first post of this thread I included a screenshot of notifications in the BIS GUI. Notice that the "Critical" tab was selected. The two relevant notifications both relate to E: (the earlier notification is expanded below as confirmation).

I'm not sure how the "Critical" tab came to be selected. I suspect it just happened automatically when I clicked on the on-screen BIS notification that popped up near the System Tray. (But I cannot exclude the possibility that I manually chose it.)

In any case, I have just discovered that in the "Warning" tab a separate notification exists related to the local copy of the file.

So I suppose I need to retract my assertions that there was no notification regarding the file on the local disk (although I didn't see any!) and that the removal couldn't be undone.

Nevertheless, I think ultimately there is at least one residual query, which is why the files on the internal and external drives are treated differently, despite both involving Application.Bundler.CZO?

Internal file (existing copy): moved to Quarantine (can be restored), and the notification is a Warning.
External file (new copy): "Blocked" (not created?), allegedly there is an option "Move to Quarantine" (but this seems impossible to do for a file that doesn't exist), and the notification is deemed Critical.

Furthermore, I recommend that clicking on the on-screen BIS notifications that pop up near the System Tray should take the user to the relevant entry with the "All" tab selected (to provide maximum context).