I want to save the log file after a sync. I know I can automatically run a batch file after a sync which copies the log file to another location but I was wondering how the log file is used (filled) by FFS.
It seems that the log file contains the log of several syncs if they are small, but with a large sync it contains only the log of the last sync or only a part of that log ?
Has the log file a maximum size (if the size is reached the oldest info gets lost) ? What is the policy of that mechanism ?
If it has a maximum size: can I change the size somewhere ?
I just discovered FFS and it's just what I needed. Thanks !!
LastSyncs.log
- Posts: 3
- Joined: 15 Jun 2011
- Posts: 74
- Joined: 17 Mar 2008
Here are two ways to solve your problem:
1. Use the versioning option in FreeFileSync and create a folder pair configured to back up JUST the LastSyncs.log file, every time you back it up, it would move your previous backup file based on the versioning option.
2. Create a specific directory to store your local sync logs (c:\logs\sync, as an example). In your normal backup configuration, add another folder pair configured to update the target folder on your server with c:\logs\sync - this will keep adding the last sync log to your backup target, you will never have to worry about overwriting the summary log file. The only issue is that the backup will always copy the *previous* log file, because the current log file is open in FreeFileSync and you will get shadow copy errors unless you elevate FreeFileSync to run with Administrator rights (Windows 7 and later). If you need examples of how to do this, let us know, it's very easy to set up.
1. Use the versioning option in FreeFileSync and create a folder pair configured to back up JUST the LastSyncs.log file, every time you back it up, it would move your previous backup file based on the versioning option.
2. Create a specific directory to store your local sync logs (c:\logs\sync, as an example). In your normal backup configuration, add another folder pair configured to update the target folder on your server with c:\logs\sync - this will keep adding the last sync log to your backup target, you will never have to worry about overwriting the summary log file. The only issue is that the backup will always copy the *previous* log file, because the current log file is open in FreeFileSync and you will get shadow copy errors unless you elevate FreeFileSync to run with Administrator rights (Windows 7 and later). If you need examples of how to do this, let us know, it's very easy to set up.
-
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
Comment on the second option: You may want to exclude the directory containing the log files via an exclude filter.
And a third option in v5.10 I just now implemented:
>Set maxiumum size of LastSyncs.log in GlobalSettings.xml element '<'LastSyncsFileSizeMax'>'
The current default is 128kB only.
And a third option in v5.10 I just now implemented:
>Set maxiumum size of LastSyncs.log in GlobalSettings.xml element '<'LastSyncsFileSizeMax'>'
The current default is 128kB only.
- Posts: 3
- Joined: 15 Jun 2011
Ok, thank You both.
@Micheal: Fine to have more options. I will keep that in mind, but do You think they are better than automatically running a batch file after the sync ? This batch file can copy the log file to another location with another name (i.e. a date in the name).
@Zenju: Good news. When will v5.10 be out ? Question: what if You have a very large sync which gives a log file that is greater than 128kB. Do You end up with an incomplete logfile ?
@Micheal: Fine to have more options. I will keep that in mind, but do You think they are better than automatically running a batch file after the sync ? This batch file can copy the log file to another location with another name (i.e. a date in the name).
@Zenju: Good news. When will v5.10 be out ? Question: what if You have a very large sync which gives a log file that is greater than 128kB. Do You end up with an incomplete logfile ?
-
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
Release is planned for Nov, 1st. Current versions of FFS will never truncate the most recent log. However this behavior will change in v5.10, which then always honors the limit (that the user is able to change).
- Posts: 8
- Joined: 3 Sep 2014
<LastSyncsLogSizeMax Bytes="100000"/> is currently at less than 100 kilobyte.
I think my recent full backup ... it only logged about 1/4 of all operations. Maybe even less than that. I am happy to learn that I can change this, but a ~98K limit is really very very small. Much of that 98K is also dedicated to time-stamps and strings like "Info:" and "File". If I strip the actual filenames and dirnames, I end up with still 31K worth of 'meta' information. So close to 1/3 of the data is somewhat superfluous. 736 lines were logged of a total of 17k+ files. So that is not 1/4, that is only 4% lol.
You make a backup and it logs 4% of what you've done. Outstanding :P. Calculating, I will need to increase the limit to 2.5 million bytes so I'll just make it 10 meg :D.
Regards, ..
I think my recent full backup ... it only logged about 1/4 of all operations. Maybe even less than that. I am happy to learn that I can change this, but a ~98K limit is really very very small. Much of that 98K is also dedicated to time-stamps and strings like "Info:" and "File". If I strip the actual filenames and dirnames, I end up with still 31K worth of 'meta' information. So close to 1/3 of the data is somewhat superfluous. 736 lines were logged of a total of 17k+ files. So that is not 1/4, that is only 4% lol.
You make a backup and it logs 4% of what you've done. Outstanding :P. Calculating, I will need to increase the limit to 2.5 million bytes so I'll just make it 10 meg :D.
Regards, ..
- Posts: 8
- Joined: 3 Sep 2014
Oh, if you think 17k files is a lot... (I don't think you do, but still, if you make these limits so low) I recently downloaded the source code to something.
I think it had about 500k files in it and something like 27k directories (in the entire tree). Some people are crazy it's true. Not talking about myself, but some programmers (Linux) apparently like burdening the filesystem with thousands upon thousands of very small files -- this whole archive was not more than 1 GB compressed. Okay, 1 GB compressed is a lot of text. But the majority of files are smaller than 10k, and the next biggest group is that of 10-20k. If you try to delete this folder structure with Windows 7, it will first spend a few vacations on "analysing" the tree (and loading all of it into memory) before doing anything. I had to delete it using "del /s /q" which didn't even delete any subdirs, only files. Back in the day we had "deltree" which was perfect. Once more, good to see we are progressing as a society :P.
"It is the mark of a primitive society to view regression as progress."
How I love the future... :D.
And how much bliss it would have been to just be able to type "rm -rf". ...
I think it had about 500k files in it and something like 27k directories (in the entire tree). Some people are crazy it's true. Not talking about myself, but some programmers (Linux) apparently like burdening the filesystem with thousands upon thousands of very small files -- this whole archive was not more than 1 GB compressed. Okay, 1 GB compressed is a lot of text. But the majority of files are smaller than 10k, and the next biggest group is that of 10-20k. If you try to delete this folder structure with Windows 7, it will first spend a few vacations on "analysing" the tree (and loading all of it into memory) before doing anything. I had to delete it using "del /s /q" which didn't even delete any subdirs, only files. Back in the day we had "deltree" which was perfect. Once more, good to see we are progressing as a society :P.
"It is the mark of a primitive society to view regression as progress."
How I love the future... :D.
And how much bliss it would have been to just be able to type "rm -rf". ...
