BACKGROUND: I have a fair amount of experience with FreeFileSync in Windows but am just a beginning user in Linux. Most of my remarks will be focused on Windows.
For some time, I have been setting up two classes of FreeFileSync batch jobs: one for syncing items that concern all users, such as "Public" (shared) data, shared portable programs, and "All Users" (ProgramData) Start Menus and Desktops; and one for syncing items that concern only the currently logged-in user, such as personal data, personal portable programs, and user-specific (AppData) Start Menus and Desktops.
I've made RealTimeSync tasks for many of these jobs. I put shortcuts for the first class of job in the "All Users" Startup folder, and shortcuts for the second class of job in the currently logged-in user's personal ("User") Startup folder. Accordingly, "All Users" RealTimeSync tasks run whenever any user logs in, and personal, "User" RealTimeSync tasks run only when the user in question logs in.
Similarly, I had set up my logs for the first class of batch files to be stored in a folder that was accessible to all users, and logs for the second class of batch files to be stored in a folder that was accessible only to the currently logged-in user. This allowed all users to check logs for syncs that affected ... well, all users ... but prevented one user from checking the logs of another user's personal syncs. This protected user privacy without affecting functionality.
Sometimes user privacy is important and legally required. I administer one small home network where one user handles (among other things) personal medical data that must be protected from disclosure, and where another user does not legally have access to that data. I can imagine similar situations involving lawyers, investigative journalists, financial analysts, and more. Sometimes, even mere filenames (as shown in logs) can reveal information that is required to be kept confidential.
Now I see that all logs will be stored in a single location.
In Linux, the default seems to be /opt/FreeFileSync/Logs (or, I'm guessing, in a new Logs subdirectory of whatever the FreeFileSync program directory happens to be).
In Windows, the default is ...\[CurrentlyLoggedInUser]\AppData\Roaming\FreeFileSync\Logs.
To my knowledge, any user can read the contents of /opt/FreeFileSync/Logs, including logs for "personal" syncs run by other users. I don't yet know how to make a "permissions template" for the logs of different batch files that would make logs of one user's batch files unreadable by other users -- or even if that's possible.
I don't yet know where the logs will go in Windows when a different user logs in and runs batch jobs.
If the default is ...\[DifferentUser]\AppData\Roaming\FreeFileSync\Logs, then some of the logs for previous "All Users" batch-job runs will be inaccessible to users who don't have Administrator privileges to snoop around in other users' profiles, or to any other user if the user's profile is encrypted.
And if the default global logs folder is changed to a location that is accessible to everyone, then everyone can see everyone else's private syncs.
Unless I am missing something important, this strikes me as a step backward in privacy, security, and/or functionality without an adequate countervailing benefit. If it was done only to simplify implementation of the new "last sync log" buttons, I'm thinking maybe it would be worth the complication of adding an extra step to read each batch file's log folder location. If I'm completely off base in my concerns, I apologize, but I would also like to know why I'm wrong.
Anyway, I don't claim to understand the pros and cons as well as the developer, but that's my initial impression as an end user. FreeFileSync is a fantastically useful utility, regardless.
Why the change in logs folder settings with 10.3?
- Posts: 32
- Joined: 7 Aug 2018
- Posts: 32
- Joined: 7 Aug 2018
My initial post was probably a case of "too long; didn't read." Let me give it another try.
Batch jobs can target different "classes" of files:
* Administrator/Root (e.g., system configuration files)
* All Users (e.g., "public," shared data files)
* Individual User (e.g., personal, private data files, personal configuration settings)
If log folders can be set at a batch-job level, as in FreeFileSync 10.2 and earlier, then Administrator/Root logs can be saved to a folder that only users with Administrator/Root privileges can access; All Users logs can be saved to a folder that all users can access; and Individual User logs can be saved to a folder that (generally speaking) only the user in question can access.
FFS 10.3 puts all log files for all classes of file in a single global folder. If the folder is one that all users can access, then ordinary users can see logs for Administrator/Root syncs and logs for other users' personal, private syncs. If the folder is one that only Administrator/Root users can access, then ordinary users cannot see the results of their own personal, private syncs. If the folder changes from a subfolder in one user profile to a subfolder in another user profile, depending on which user is logged in, then Administrator/Root logs and All Users logs are divided up into multiple locations.
As I understand it so far, this is an unwelcome loss of privacy, security, functionality, and/or convenience. I strongly advocate returning to batch-job-level log folders.
Batch jobs can target different "classes" of files:
* Administrator/Root (e.g., system configuration files)
* All Users (e.g., "public," shared data files)
* Individual User (e.g., personal, private data files, personal configuration settings)
If log folders can be set at a batch-job level, as in FreeFileSync 10.2 and earlier, then Administrator/Root logs can be saved to a folder that only users with Administrator/Root privileges can access; All Users logs can be saved to a folder that all users can access; and Individual User logs can be saved to a folder that (generally speaking) only the user in question can access.
FFS 10.3 puts all log files for all classes of file in a single global folder. If the folder is one that all users can access, then ordinary users can see logs for Administrator/Root syncs and logs for other users' personal, private syncs. If the folder is one that only Administrator/Root users can access, then ordinary users cannot see the results of their own personal, private syncs. If the folder changes from a subfolder in one user profile to a subfolder in another user profile, depending on which user is logged in, then Administrator/Root logs and All Users logs are divided up into multiple locations.
As I understand it so far, this is an unwelcome loss of privacy, security, functionality, and/or convenience. I strongly advocate returning to batch-job-level log folders.
-
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
As I understand, you see the log files not as some mere technical data, but as business data that logically belongs to a particular sync job.
If this is a general requirement, then the log file path should not simply be put back into the batch creation dialog, but instead be included into the sync config dialog, so that it's evaluated for non-batch syncs, too.
What do you think about the switch from limiting the number of log files by count towards limiting by days since creation?
What about the deprecation and removal of "%AppData%\FreeFileSync\LastSyncs.log"? No complaints, anyone?
If this is a general requirement, then the log file path should not simply be put back into the batch creation dialog, but instead be included into the sync config dialog, so that it's evaluated for non-batch syncs, too.
What do you think about the switch from limiting the number of log files by count towards limiting by days since creation?
What about the deprecation and removal of "%AppData%\FreeFileSync\LastSyncs.log"? No complaints, anyone?
- Posts: 29
- Joined: 9 Feb 2016
Zenju,
All your suggestions are spot on. I think this should solve most if not all the issues in 10.3. looking forward to these changes.
Thank you
All your suggestions are spot on. I think this should solve most if not all the issues in 10.3. looking forward to these changes.
Thank you
- Posts: 1
- Joined: 12 Aug 2018
Hi,
I would also very much appreciate to keep the logs with the backup data as it was until V10.2. So you always have it beside your data, regardless if it's a NAS, external harddisk, USB-Stick ... and not at a central location where you have to locate a specific log and assign it to its backup.
Also it is a problem that not every backup is done by the same user, so log files will be spread over different directories (or did I miss a way to specify the directory!?)
If someone really needs the new scheme ... you can perhaps offer a switch to choose the way of logging!?
Regards
Dirk
I would also very much appreciate to keep the logs with the backup data as it was until V10.2. So you always have it beside your data, regardless if it's a NAS, external harddisk, USB-Stick ... and not at a central location where you have to locate a specific log and assign it to its backup.
Also it is a problem that not every backup is done by the same user, so log files will be spread over different directories (or did I miss a way to specify the directory!?)
If someone really needs the new scheme ... you can perhaps offer a switch to choose the way of logging!?
Regards
Dirk
- Posts: 102
- Joined: 14 Feb 2015
Hardcoded Logpath ist not useful!
When script is runnning with the user "System" (Windows) nobody has access to that APPDATA in the normal way...
ffs with scripting there are different user options ...
Running per GPO Shutdown-Script : ffs run is with the user SYSTEM
running same script from desktop its a useraccount.
so ... same ffs-task has different logpaths ... not good.
When script is runnning with the user "System" (Windows) nobody has access to that APPDATA in the normal way...
ffs with scripting there are different user options ...
Running per GPO Shutdown-Script : ffs run is with the user SYSTEM
running same script from desktop its a useraccount.
so ... same ffs-task has different logpaths ... not good.
- Posts: 102
- Joined: 14 Feb 2015
Addition: Option:
When user has no Logpath defined then use appdata...
else leave the individual Logpath as it is.
For me "Hold the last "n" Logfiles" is the best option.
volker01
When user has no Logpath defined then use appdata...
else leave the individual Logpath as it is.
For me "Hold the last "n" Logfiles" is the best option.
volker01
- Posts: 68
- Joined: 13 Aug 2018
Hi Zenju,
please let the user change the option to set the log path - as it was in the past. It doesn't make sense to write the log files to the user profile path. I want to have saved the logs of my tools in a central path. And since 10.3 the freefilesync.vbs script send mails with warnings because the log files couldn't be located by the script any more.
What is meant by the new option "•New %logfile_path% macro for "on completion" " in the change log? How can I use this? What is it doing?
Thank You
TheExpert
please let the user change the option to set the log path - as it was in the past. It doesn't make sense to write the log files to the user profile path. I want to have saved the logs of my tools in a central path. And since 10.3 the freefilesync.vbs script send mails with warnings because the log files couldn't be located by the script any more.
What is meant by the new option "•New %logfile_path% macro for "on completion" " in the change log? How can I use this? What is it doing?
Thank You
TheExpert
- Posts: 5
- Joined: 17 Aug 2017
I want to express my displeasure with the changes to the LOG FILE.
Why keep just 14?
Why put them in ROAMING app folder when they are relevant to only the machine they ran on?
Make these options the USER can choose. What are you Microsoft (someone who forces every change upon the masses)?
Why keep just 14?
Why put them in ROAMING app folder when they are relevant to only the machine they ran on?
Make these options the USER can choose. What are you Microsoft (someone who forces every change upon the masses)?
- Posts: 1
- Joined: 14 Aug 2018
Please restore the ability to specify the logfile location. You must have spent time, effort, and money to make this change, but can't imagine why you thought that was a good idea, much less a cost effective change.
- Posts: 6
- Joined: 10 Aug 2018
After reading all the above comments, it seems that the general consensus is as I replied in posts here earlier;
“This change forcing a location for log files after updating to 10.3 is totally illogical and heavy-handed, as well as impractical and inconvenient for many. Such an arbitrary and authoritarian decision assumes that the programmer at minimum think he/she knows better than the user, or worse does not care what the user wants or needs.”
And the above comments give a number of great reasons this is true. Please consider correcting this and allowing the user to make their on decisions that fit their needs, situation, and usage.
“This change forcing a location for log files after updating to 10.3 is totally illogical and heavy-handed, as well as impractical and inconvenient for many. Such an arbitrary and authoritarian decision assumes that the programmer at minimum think he/she knows better than the user, or worse does not care what the user wants or needs.”
And the above comments give a number of great reasons this is true. Please consider correcting this and allowing the user to make their on decisions that fit their needs, situation, and usage.
- Posts: 5
- Joined: 17 Aug 2017
re Gama
That is a beautifully worded statement!!! Change the first clause and it can be sent to half the corporations that write applications!“This change forcing a location for log files after updating to 10.3 is totally illogical and heavy-handed, as well as impractical and inconvenient for many. Such an arbitrary and authoritarian decision assumes that the programmer at minimum think he/she knows better than the user, or worse does not care what the user wants or needs.”
- Posts: 6
- Joined: 10 Aug 2018
True, but first I think it would be much more than half the corporations that write applications. And it is only this way because we allow it to be. However, I cannot with a good conscience stand by while such a travesty happens to such a useful and great product that I have used and loved for a number of years.re GamaThat is a beautifully worded statement!!! Change the first clause and it can be sent to half the corporations that write applications! joefiesta, 14 Aug 2018, 19:01“This change forcing a location for log files after updating to 10.3 is totally illogical and heavy-handed, as well as impractical and inconvenient for many. Such an arbitrary and authoritarian decision assumes that the programmer at minimum think he/she knows better than the user, or worse does not care what the user wants or needs.”
- Posts: 1
- Joined: 15 Aug 2018
Sometimes user privacy is important and legally required. I administer one small home network where one user handles personal medical data that must be protected from "disclosure"
- Posts: 6
- Joined: 15 Aug 2018
Hi All,
I have been using Freefilesync for 3 weeks and it works great so I have just donated and I got this donation copy, so I have installed this but noticed that the log files were no longer going to where I wanted them. I spent a few hours trying to work out why and then came here to the forum to see that it was a 10.3 change.
From a new user, please could you look at putting the log files back as they were, it will be a simple change as it was already coded that way. Thanks
I have been using Freefilesync for 3 weeks and it works great so I have just donated and I got this donation copy, so I have installed this but noticed that the log files were no longer going to where I wanted them. I spent a few hours trying to work out why and then came here to the forum to see that it was a 10.3 change.
From a new user, please could you look at putting the log files back as they were, it will be a simple change as it was already coded that way. Thanks
-
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
The old batch-specific log folder path has now been turned into an override setting of the global default log path which is available for both gui and batch syncs. (See sync config dialog)
Let me know if there are any issues:
https://www.mediafire.com/file/oqv2x2e4ut1axdk/FreeFileSync_10.4_%5BBeta%5D_Windows_Setup.exe
Everyone can relax now.
Let me know if there are any issues:
https://www.mediafire.com/file/oqv2x2e4ut1axdk/FreeFileSync_10.4_%5BBeta%5D_Windows_Setup.exe
Everyone can relax now.
- Posts: 6
- Joined: 10 Aug 2018
This worked flawlessly for me. Thank you for paying attention to and understanding us, and then quickly responding and fixing it. I wish more of those that write applications would follow your example.The old batch-specific log folder path has now been turned into an override setting of the global default log path which is available for both gui and batch syncs. (See sync config dialog)
Let me know if there are any issues:
https://www.mediafire.com/file/oqv2x2e4ut1axdk/FreeFileSync_10.4_%5BBeta%5D_Windows_Setup.exe
Everyone can relax now. Zenju, 15 Aug 2018, 16:55
- Posts: 6
- Joined: 15 Aug 2018
Thanks, will the auto update on the donation copy auto update or is the mediafire copy a special one off? I am asking as my donation copy 10.3 says it is uptodate .ThanksThe old batch-specific log folder path has now been turned into an override setting of the global default log path which is available for both gui and batch syncs. (See sync config dialog)
Let me know if there are any issues:
https://www.mediafire.com/file/oqv2x2e4ut1axdk/FreeFileSync_10.4_%5BBeta%5D_Windows_Setup.exe
Everyone can relax now. Zenju, 15 Aug 2018, 16:55
- Posts: 68
- Joined: 13 Aug 2018
Thank you very much for bringing this option back. Now, everything is working as in the past :-)The old batch-specific log folder path has now been turned into an override setting of the global default log path which is available for both gui and batch syncs. (See sync config dialog)
Let me know if there are any issues:
https://www.mediafire.com/file/oqv2x2e4ut1axdk/FreeFileSync_10.4_%5BBeta%5D_Windows_Setup.exe
Everyone can relax now. Zenju, 15 Aug 2018, 16:55
- Posts: 102
- Joined: 14 Feb 2015
Thank you,
works as expected.
volker01
works as expected.
volker01
- Posts: 2
- Joined: 18 Aug 2018
And for Macs?
- Posts: 4
- Joined: 19 Aug 2018
Thanks for the update to 10.4 (Beta). 10.3 broke everything. How do I get back to the Donation Edition when 10.4 is properly released.
PS: PLEASE don't make such dramatic changes again without full user consultation. FreeFileSync is great, and I had little realised what a complete disaster it would be if it broke.
David
PS: PLEASE don't make such dramatic changes again without full user consultation. FreeFileSync is great, and I had little realised what a complete disaster it would be if it broke.
David
- Posts: 1
- Joined: 20 Aug 2018
Thank you for this quick fix. I use FFS to back up to a USB drive which I take to another site and need the logfile to go with the drive. I've managed to restore my batch files which I think FFS 10.3 automatically re-wrote, without so much as a "by-your-leave" or "may-I".!!!!!
- Posts: 32
- Joined: 7 Aug 2018
My apologies for the long delay in responding, Zenju. After a technical change by my local broadband monopoly, I began having terrible Internet connectivity problems that I'm still trying to diagnose and fix.
I see the log files as potentially revealing metadata, like an individual's phone-call history or GPS tracking data. It doesn't necessarily tell third parties exactly what happened, but it can give them a very good idea, depending on whose files are being synced and how revealing the filenames are. I guess that qualifies as business data. At any rate, FFS/RTS administrators need to be able to control where the logs are stored and who can access them. I see from a later post that you are restoring this feature. Thank you!
I'm embarrassed to say this, but I didn't even stop to think about ordinary, non-batch FFS jobs because I don't think I've ever made one. I believe I've always saved even my single-folder-pair jobs as batch jobs, because I end up making RTS tasks for so many of them. (I don't even know where logs for non-batch jobs go.)
As for capping the number of logs by age as opposed to by number, I'm thinking it's probably a good move. If FFS/RTS administrators make changes that accidentally result in an abnormally large number of syncs, they will still have X days to review the logs for all of the subsequent syncs.
Which reminds me: The age and number caps for versioned backups that came with FFS 10.2 were an extremely useful development, eliminating the time-sucking hassle of periodic manual maintenance. THANK YOU! I see in this thread that some people want to continue capping the number of log files by number instead of age. Do you think maybe a dual-cap system similar to the one used for versioned backups would make everyone happy?
I didn't even pick up on the deprecation of the LastSyncs.log, because (as with non-batch jobs), I never use it -- I always look at the logs for a given batch job. Hopefully, other users will have useful feedback on this change
Thanks very much for a great program and for being so responsive. (I wish my ISP were half as good in both respects...) I'm looking forward to the official release of 10.4. All the best.
I see the log files as potentially revealing metadata, like an individual's phone-call history or GPS tracking data. It doesn't necessarily tell third parties exactly what happened, but it can give them a very good idea, depending on whose files are being synced and how revealing the filenames are. I guess that qualifies as business data. At any rate, FFS/RTS administrators need to be able to control where the logs are stored and who can access them. I see from a later post that you are restoring this feature. Thank you!
I'm embarrassed to say this, but I didn't even stop to think about ordinary, non-batch FFS jobs because I don't think I've ever made one. I believe I've always saved even my single-folder-pair jobs as batch jobs, because I end up making RTS tasks for so many of them. (I don't even know where logs for non-batch jobs go.)
As for capping the number of logs by age as opposed to by number, I'm thinking it's probably a good move. If FFS/RTS administrators make changes that accidentally result in an abnormally large number of syncs, they will still have X days to review the logs for all of the subsequent syncs.
Which reminds me: The age and number caps for versioned backups that came with FFS 10.2 were an extremely useful development, eliminating the time-sucking hassle of periodic manual maintenance. THANK YOU! I see in this thread that some people want to continue capping the number of log files by number instead of age. Do you think maybe a dual-cap system similar to the one used for versioned backups would make everyone happy?
I didn't even pick up on the deprecation of the LastSyncs.log, because (as with non-batch jobs), I never use it -- I always look at the logs for a given batch job. Hopefully, other users will have useful feedback on this change
Thanks very much for a great program and for being so responsive. (I wish my ISP were half as good in both respects...) I'm looking forward to the official release of 10.4. All the best.
- Posts: 6
- Joined: 14 Dec 2016
(Copy/pasted my reaction here, from this thread.)
I went back to FreeFileSync_10.2_[Donation_Edition]_Setup.exe
After a few days of using 10.3 I noticed that my modified files did not appear at my Cloud Provider.
I soon found out that my own scripts work fine with 10.2 but not with 10.3. Due to the change "Deprecated batch-level log files and LastSyncs.log".
I understand the need for a timestampedlog, but I rely heavily on the "old&fixedlocated LastSyncs.log".
For example; I inspect LastSyncs.log in order to:
1) "Encrypt my files to my NAS (afterward the Synology NAS package Cloud Sync tranfers the encrypted files to my Cloud Provider)".
2) Some files go to other locations, such as my smartphone.
Perhaps it's "doable" to inspect the "C:\Users\Gordon\AppData\Roaming\FreeFileSync\Logs"-folder for the new logfile (every time after a FFS-run!), but for now (little time) I choose 10.2 because I know for sure its name&location and I don't have to search for the logfile.
If I understand this thread correctly, upcoming version 10.4 will allow users to choose between different locations (perhaps even with 'placeholders' in de logfilename).
I'll look forward to 10.4.
I went back to FreeFileSync_10.2_[Donation_Edition]_Setup.exe
After a few days of using 10.3 I noticed that my modified files did not appear at my Cloud Provider.
I soon found out that my own scripts work fine with 10.2 but not with 10.3. Due to the change "Deprecated batch-level log files and LastSyncs.log".
I understand the need for a timestampedlog, but I rely heavily on the "old&fixedlocated LastSyncs.log".
For example; I inspect LastSyncs.log in order to:
1) "Encrypt my files to my NAS (afterward the Synology NAS package Cloud Sync tranfers the encrypted files to my Cloud Provider)".
2) Some files go to other locations, such as my smartphone.
Perhaps it's "doable" to inspect the "C:\Users\Gordon\AppData\Roaming\FreeFileSync\Logs"-folder for the new logfile (every time after a FFS-run!), but for now (little time) I choose 10.2 because I know for sure its name&location and I don't have to search for the logfile.
If I understand this thread correctly, upcoming version 10.4 will allow users to choose between different locations (perhaps even with 'placeholders' in de logfilename).
I'll look forward to 10.4.
-
- Posts: 2450
- Joined: 22 Aug 2012
@GordonFFS:
There was no need to copy/paste your earlier message.
I pointed you here because, as you could have read above, the issue will be resolved in V10.4, which you can verify with a Beta release of V10.4.
For your problem: simply keep using V10.2 until V10.4 is released.
There was no need to copy/paste your earlier message.
I pointed you here because, as you could have read above, the issue will be resolved in V10.4, which you can verify with a Beta release of V10.4.
For your problem: simply keep using V10.2 until V10.4 is released.
- Posts: 1
- Joined: 28 Aug 2018
Please, please, undo the log file restrictions as introduced in version 10.3 and set everything (according to log files) back as it was in version 10.2.
- Posts: 3
- Joined: 9 Aug 2018
Thank you for changing the log file options in 10.4! Really appreciated!
- Posts: 10
- Joined: 9 Aug 2018
Thank you for possibility override default log path in version 10.4 .
- Posts: 3
- Joined: 13 Feb 2018
Hi,
I experienced the problem (for me) with the changed logfile directory. In my home environment I ask my family members to check the logfile for the daily batch jobs, which were configured to be found in the users home directory.
Now I'm trying the 10.4 where this should be fixed but I cannot find a place, where and how I can change the logpath.
In earlier versions there was a possibility when I used the "save as batch" dialog. There is no now.
The default path in the options menu cannot be changed. "Overriding" mentioned in the previous post by typing something in does not work and the icon in front of the path field has no function.
It would be great, if one can point me to the location where and how I can change the logfile path for specific batch jobs.
I experienced the problem (for me) with the changed logfile directory. In my home environment I ask my family members to check the logfile for the daily batch jobs, which were configured to be found in the users home directory.
Now I'm trying the 10.4 where this should be fixed but I cannot find a place, where and how I can change the logpath.
In earlier versions there was a possibility when I used the "save as batch" dialog. There is no now.
The default path in the options menu cannot be changed. "Overriding" mentioned in the previous post by typing something in does not work and the icon in front of the path field has no function.
It would be great, if one can point me to the location where and how I can change the logfile path for specific batch jobs.
