(stubact.log) File reading error

I'm using PB&R Free to backup a Windows 7 Pro machine (full backups only), and as far as I can tell, the backups are completing successfully. However, when I try to view the logs using the built-in log viewer, the following error dialog appears:

clicking the More options button reveals:

Entries in the Session Entries pane on the upper left are appearing, with start and end times, but all other panes show some variation of "No information available."

I tried deleting stubact.log and letting B & R re-create it, but the same issue appears. It doesn't seem to matter if the log is empty or has several entries. I thought it might be a permissions issue, but a permissions check reveals that the file in question is readable and modifiable by all users. The text in the file itself doesn't look obviously corrupted in any way. It may seem kind of nitpicky, as I can view the log file in a text editor, but I like the built-in log interface much better. It makes it easier to keep track of multiple backups. I'm using B&R on another machine in the office of a small nonprofit where I'm volunteering, and it seems to work fine. I haven't yet actually tried to restore a backup yet, so I suppose I should try that anyway. Still, I'm debating recommending the full version of this software to the office exec, until I can get this 'un to behave reliably.

Any suggestions would be greatly appreciated!

EDIT: I tried a repair install, no effect. I tried uninstalling and re-installing, as well as removing the old stubact.log file. At first I thought I'd solved it, as when the log was still blank, I didn't get that error message. However, as soon as I scheduled a backup (even before the backup could start) and I tried to view the log, the same error message popped back up! Grr!

Edit 2: I thought that perhaps it might be a problem with how cancelled backups are logged, so I started and cancelled a backup on the other machine that's been working (a laptop, also with Win 7 pro). But nope, no error message on that one.

 

Lots of views but no comments yet. Am I the only one having this problem?

 

NO

I am running HDM12 Pro on a Win7 Pro x64. Viewing the log has always given me error messages, but not exactly the same you have. Please look at my attached screen-shot. Of the 8 logged entries 3 are readable, 5 are giving 'File parsing error'.

I have ignored this malfunction because the backup/restore has worked flawlessly.

But of course, the log function should not be like that.

 

I think you should raise a support ticket with Paragon especially since you have a paid version. For them, no news is good news.

Maybe I should start reading my logs and see what they do!

 

Have you guys attempted to truncate the logs?

 

I get a file parsing error as well.

It doesn't seem to matter what size the log is.

I just assumed it was a bug.

I only notice it in the 12 series -didn't happen with 9,10 and 11 series.

 

I actually got a file parsing error several times during my attempts to fix the problem (by deleting and allowing the log to be recreated, for instance) but I figured it was just a result of my meddling.

I have - it doesn't seem to change anything unless I clear the log entirely, and then the problem crops up again as soon as anything gets written into the log.

 

I have never previously truncated the log. Yesterday I performed a test, "Remove all data except last 2 days". Result: No entries were deleted, but the entries for the last 2 days were duplicated.

I then selected the option “Clear log file”. Result: Everything was deleted.

Today I ran a differential backup. Result: “File parsing error. Wrong or unsupported file format. File .\stubact.log parsing error. Expected . at line 314”

Line 314 reads like this:
>> BaseArchive: W:/Egne data/Backup/Paragon Backup/arc_181212201836967/img_1_181212_202036354.pbf

 

@John Doe Genius: I noticed your drive letter is W:
Are you by any chance backing up to a network drive? That's what I'm doing, and I'm wondering if it has something to do with this issue. While it doesn't explain why the other machine works just fine (same network), I'm backing up to a NAS I'm mapping as drive N. The odd thing I've noticed, though, with the other machine, is that it won't work unless I go into the script and change the path from N:/Backupfolder to //NETWORK-DRIVE/Backupfolder

Adding to the confusion for me (this is the first time I've used network drives) is that apparently Windows treats forward and backslashes interchangeably, but the app only seems to use forward slashes, Linux style.

Again, the other machine backs up just fine when the path is changed from a mapped drive letter to the actual network path, but I'm wondering if this could be a piece of the puzzle...

 

@aceshangar
Drive W: is a local HD, an external USB drive from Western Digital; I just used Computer Management to change the drive letter to W: (that was suitable for a WD drive!).

 

@John Doe Genius: Oh, I see. Rats. Thought maybe I was on to something

No one else has had any luck, sounds like?
This is a bummer. I guess I have to keep looking for different backup solutions

 

Getting the same parsing error message for all log files. I'm backing up to a Western Digital NAS.

I am able to open the .log files using Notepad, but I can't decipher the logs to determine why a backup failed. Does anyone have any info on how to read these logs?

Thanks in advance for any feed back.

 

Hey guys after double checking into this error, I was told it is something development is aware of, and is working on currently.

 

Hi Peeps!

I'm new here. Any word of a fix for this?

I'm still getting these errors. I've been lucky so far because I've found one of my Paragon product's restore functions has so far worked. I'm worried that all will fail for a critical restore for me soon.

Thanks!