hello,
FreeFileSync 14.8 Donation Edition. I use a series of real-time two-way sync jobs that work perfectly on multiple computers (four) and a NAS (which contains the pivot folders). These backups run via scheduled tasks every time the computers are turned on and remain running until they are shut down. The problem I'm reporting is visible in the following two images:
Now, let's make a few considerations:
1) The log files are written locally on each computer and cannot be interfered with by other computers.
2) I never manually delete the log files, nor do I write or copy files to their designated folders. I let FreeFileSync manage the folder, deleting log files older than two days.
3) For each sync operation, the log files are written to a folder dedicated exclusively to that operation; therefore, each folder contains only the log files for that operation.
4) For all real-time jobs, the idle time has been set to 10 seconds.
That said, why is it impossible to:
a) Delete (ERROR_FILE_NOT_FOUND) a log file that doesn't appear to exist if the message specifies an exact file name, which is therefore known to FreeFileSync and therefore must exist?
b) Create (ERROR_FILE_EXISTS) a log file for an operation performed a moment ago because the file appears to already exist? (Back to the future? :-) How can a log file exist for that exact timestamp and for that job if it was just done?)
The only clue I have is that this only happens on the first boot of the day on all four computers. All subsequent real-time runs throughout the day never generate such errors. The only thing I can think of is that there's some problem generating the unique file names.
As an example, I'm attaching the files from one of my synchronization tasks (my email client): the .ffs_batch file, the .ffs_real file, and the scheduled task file.
I hope you can help. It's not a serious issue, but it's annoying.
Thank you.
Salvatore
Logging issue
- Posts: 24
- Joined: 30 Mar 2023
- Attachments
-
- Betterbird scheduled job.xml
- (3.65 KiB) Downloaded 17 times
-
- Betterbird.ffs_real
- (426 Bytes) Downloaded 23 times
-
- Betterbird.ffs_batch
- (2.28 KiB) Downloaded 24 times
-
- Posts: 2978
- Joined: 22 Aug 2012
The only thing I can tell from what you shared, is that the Betterbird.ffs_batch configuration does not have a checkmark in the "Change log folder" box, and thus does not specify your Betterbird log-file location, but instead uses the default log-file location.
You only refer to a Betterbird location for Versioning.
You only refer to a Betterbird location for Versioning.
- Posts: 24
- Joined: 30 Mar 2023
hello Plerry,
you are right. I made a bit of confusion between the version files, that are written in their own folder for every job, and the log files that are written all in the same default local folder, %appdata%\FreeFileSync\Logs. I haven't used the checkbox that you mentioned in your reply.
But the fact remains that FFS tries to write a second log with a file name exactly equal to another (ERROR_FILE_EXISTS); this should not happen, even if the log folder is always the same, because an operation for the same job cannot be run two times at the same exact timestamp, thus generating the same "unique" filename. Or am I wrong? And I also suppose that the error ERROR_FILE_NOT_FOUND should never happen as well, because I suppose that (maybe) FFS keeps track of all the created log files and thus the file should exist. This is also because a job, wether it completes with or without errors, should always generate a log file with a unique name, right?
Thank you
Salvatore
you are right. I made a bit of confusion between the version files, that are written in their own folder for every job, and the log files that are written all in the same default local folder, %appdata%\FreeFileSync\Logs. I haven't used the checkbox that you mentioned in your reply.
But the fact remains that FFS tries to write a second log with a file name exactly equal to another (ERROR_FILE_EXISTS); this should not happen, even if the log folder is always the same, because an operation for the same job cannot be run two times at the same exact timestamp, thus generating the same "unique" filename. Or am I wrong? And I also suppose that the error ERROR_FILE_NOT_FOUND should never happen as well, because I suppose that (maybe) FFS keeps track of all the created log files and thus the file should exist. This is also because a job, wether it completes with or without errors, should always generate a log file with a unique name, right?
Thank you
Salvatore
-
- Site Admin
- Posts: 7523
- Joined: 9 Dec 2007
Is it possible that you have multiple RTS instances running, which then will start multiple FFS processes at the exact same time?
- Posts: 24
- Joined: 30 Mar 2023
hello Zenju,
yes, I have one instance for every job, see pictures:
This is task manager:
And these are the six different jobs (this means that each job cannot generate an unique file name identical to that of another job, since the unique name for the log file includes also the job name):
But strangely, from two or three days this phenomenon has ceased, but I don't know why.
Thank you
Sal
yes, I have one instance for every job, see pictures:
This is task manager:
And these are the six different jobs (this means that each job cannot generate an unique file name identical to that of another job, since the unique name for the log file includes also the job name):
But strangely, from two or three days this phenomenon has ceased, but I don't know why.
Thank you
Sal
- Posts: 24
- Joined: 30 Mar 2023
hello,
I partially amend my last message: the phenomenon has ceased on all computers but one (an HP notebook) that still gives the problem. Please, look at the picture below:
I have also attached the complete text for today's log of the problematic notebook, since the image doesn't show all errors.
While this PC was on, another PC (where errors have ceased to appear) was on as well, and every now and then an application on this second computer generated changes that were syncronized. Of course these changes triggered syncronization on the notebook as well.
At this point, how could errors like those pictured happen if the sync has been just performed and then a log file for that job with that timestamp could not exist?
Thank you
Sal
I partially amend my last message: the phenomenon has ceased on all computers but one (an HP notebook) that still gives the problem. Please, look at the picture below:
I have also attached the complete text for today's log of the problematic notebook, since the image doesn't show all errors.
While this PC was on, another PC (where errors have ceased to appear) was on as well, and every now and then an application on this second computer generated changes that were syncronized. Of course these changes triggered syncronization on the notebook as well.
At this point, how could errors like those pictured happen if the sync has been just performed and then a log file for that job with that timestamp could not exist?
Thank you
Sal
- Attachments
-
- 2026-03-25 Log.txt
- (2.07 KiB) Downloaded 23 times
- Posts: 24
- Joined: 30 Mar 2023
hello,
today it happened again on a computer where the problem seemed to be ceased:
It happened this morning, at the first power on of the day for this computer. FFS tried to delete a log file of March 23 that should have been already deleted, since I keep the logs of the last two days. I anticipate the question: I power on all the computers every day, so it seems to me that FFS forgot that log somehow.
The problem on the notebook still persists.
Sal
today it happened again on a computer where the problem seemed to be ceased:
It happened this morning, at the first power on of the day for this computer. FFS tried to delete a log file of March 23 that should have been already deleted, since I keep the logs of the last two days. I anticipate the question: I power on all the computers every day, so it seems to me that FFS forgot that log somehow.
The problem on the notebook still persists.
Sal
- Posts: 24
- Joined: 30 Mar 2023
hello,
first power on of this computer (that should have ceased to produce these errors). Today is the 27th, FFS is set up to delete logs after two days, so it should search and remove logs of 25th, but today it's trying to delete logs of 24th. I've inspected the log folder and I still have 286 logs of 25th that today should have been deleted and no other logs older than these. Definitely there there could be something wrong in the log maintenance.
Sal
first power on of this computer (that should have ceased to produce these errors). Today is the 27th, FFS is set up to delete logs after two days, so it should search and remove logs of 25th, but today it's trying to delete logs of 24th. I've inspected the log folder and I still have 286 logs of 25th that today should have been deleted and no other logs older than these. Definitely there there could be something wrong in the log maintenance.
Sal