![]() ![]() ![]() 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. Unless I am missing something important, this strikes me as a step backward in privacy, security, and/or functionality without an adequate countervailing benefit. \\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.Īnd 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. I don't yet know where the logs will go in Windows when a different user logs in and runs batch jobs. 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. To my knowledge, any user can read the contents of /opt/FreeFileSync/Logs, including logs for "personal" syncs run by other users. ![]() 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). Now I see that all logs will be stored in a single location. Sometimes, even mere filenames (as shown in logs) can reveal information that is required to be kept confidential. I can imagine similar situations involving lawyers, investigative journalists, financial analysts, and more. 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. Sometimes user privacy is important and legally required. This protected user privacy without affecting functionality. but prevented one user from checking the logs of another user's personal syncs. This allowed all users to check logs for syncs that affected. 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. ![]() 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. 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. I've made RealTimeSync tasks for many of these jobs. Most of my remarks will be focused on Windows.įor 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. BACKGROUND: I have a fair amount of experience with FreeFileSync in Windows but am just a beginning user in Linux. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |