Hi,
I would like to ask if it is possible to implement FFS an option allowing to preserve the dates and times of copied directories. I have already found an answer in the forum that the behavior of FFS is the same as Windows explorer does, however this is what I would like to use differently. Do you consider to implement this feature in the future or is it for some reason not possible? Thank you.
Best regards,
Pavel
Preserving dates and times of directories
- Posts: 2
- Joined: 23 Nov 2012
- Posts: 2
- Joined: 1 Nov 2014
I'll try to explain this to the best of my knowledge and as to how I understand this may happen.
FFS does keep the creation date in directories, it doesn't however, keep the modified date in sync. On the initial syncing, the folder will have the same modified date and creation date, on both sides. The folder is copied as is, all attributes. It doesn't however, keep the modified date in sync, since syncing only overwrites/syncs files and not the folder itself.
When a file changes and is compared by modified date, the file is copied over and overwrites the older one. When a folder's contents changes, its date modified changes and then what? you can't just simply re-copy the folder like you do with files because the folder is already there, and if that is done all files will be overwritten all over again. Should it just copy the date modified attribute on a folder that had its files changed? It already made changes to the files within the folder and hence why the modified date changed on the folder to the date you did the sync. A folder is created just once and both dates are preserved since it is well a "creation" and attributes are copied over, files however, are always changing and are copied over/overwritten, an overwrite is a "creation" and all attributes go with it all, just like with a folder's first sync. When you sync files, you are either overwriting or deleting what doesn't exist. Renames do not change the date modified attribute hence, why they simply are always in sync during renames.
FFS compares files themselves, it looks at the file level, it doesn't really compare folder modified date, just whether it exists or not. It doesn't take folders attributes as a syncing object unless the folder doesn't exist on one of the sides or it had its name changed, since files by themselves indicate what needs to be synced. It doesn't scan and say "hey this folder changed, lets sync the files or lets overwrite the entire folder again". It looks at the files and simply syncs the files, since the folders attributes have no use in the syncing process.
It is possible to copy just the attribute, and it is rather simple. The complex part would be using folders as a syncing object. They would have to now be considered each time whether or not a file is compared. I guess this would lengthen the scan process quite a bit, since now, you would have to check thousands of folders and compare them. Or, should they just be considered only for the detected changed file's root directory? E.g: if a file changes in c:\a\ and not in c:\b\ ignore modified date comparison of b and just do a?
In summary, folder attributes have no use in the comparison algorithm since the files are the ones that dictate what transfers over. Both creation date and modified date are synced on an initial sync because it is a new creation. The creation date of folders is retained always since folders are only created once, and then have their file contents modified which are the ones being edited. Only when a folder is deleted or renamed it is actually considered since now the "table" of changes has had an entry added, removed, or edited. It is the nature of the beast, since files and folders only keep the dates when copied and recreated new or overwritten. For FFS to keep the modified date the same just as it does with files, it would have to recopy and overwrite the entire folder as a "whole". But since it doesn't do that, and instead syncs the "content" that changed, it needs to be copied manually some other way.
FFS does keep the creation date in directories, it doesn't however, keep the modified date in sync. On the initial syncing, the folder will have the same modified date and creation date, on both sides. The folder is copied as is, all attributes. It doesn't however, keep the modified date in sync, since syncing only overwrites/syncs files and not the folder itself.
When a file changes and is compared by modified date, the file is copied over and overwrites the older one. When a folder's contents changes, its date modified changes and then what? you can't just simply re-copy the folder like you do with files because the folder is already there, and if that is done all files will be overwritten all over again. Should it just copy the date modified attribute on a folder that had its files changed? It already made changes to the files within the folder and hence why the modified date changed on the folder to the date you did the sync. A folder is created just once and both dates are preserved since it is well a "creation" and attributes are copied over, files however, are always changing and are copied over/overwritten, an overwrite is a "creation" and all attributes go with it all, just like with a folder's first sync. When you sync files, you are either overwriting or deleting what doesn't exist. Renames do not change the date modified attribute hence, why they simply are always in sync during renames.
FFS compares files themselves, it looks at the file level, it doesn't really compare folder modified date, just whether it exists or not. It doesn't take folders attributes as a syncing object unless the folder doesn't exist on one of the sides or it had its name changed, since files by themselves indicate what needs to be synced. It doesn't scan and say "hey this folder changed, lets sync the files or lets overwrite the entire folder again". It looks at the files and simply syncs the files, since the folders attributes have no use in the syncing process.
It is possible to copy just the attribute, and it is rather simple. The complex part would be using folders as a syncing object. They would have to now be considered each time whether or not a file is compared. I guess this would lengthen the scan process quite a bit, since now, you would have to check thousands of folders and compare them. Or, should they just be considered only for the detected changed file's root directory? E.g: if a file changes in c:\a\ and not in c:\b\ ignore modified date comparison of b and just do a?
In summary, folder attributes have no use in the comparison algorithm since the files are the ones that dictate what transfers over. Both creation date and modified date are synced on an initial sync because it is a new creation. The creation date of folders is retained always since folders are only created once, and then have their file contents modified which are the ones being edited. Only when a folder is deleted or renamed it is actually considered since now the "table" of changes has had an entry added, removed, or edited. It is the nature of the beast, since files and folders only keep the dates when copied and recreated new or overwritten. For FFS to keep the modified date the same just as it does with files, it would have to recopy and overwrite the entire folder as a "whole". But since it doesn't do that, and instead syncs the "content" that changed, it needs to be copied manually some other way.
- Posts: 1
- Joined: 18 Feb 2015
Your explanation makes sense, but a couple of additional thoughts here. First, each top level folder in the folder pairs has the modify date changed every time the sync is run, regardless of whether any changes are made or not. That's because of the "sync.ffs_lock" that gets updated in the folder. So this is one thing that is a bit of a "false positive" on the time stamp. This one is minor, but potentially something that could be addressed.I'll try to explain this to the best of my knowledge and as to how I understand this may happen.
FFS does keep the creation date in directories, it doesn't however, keep the modified date in sync. On the initial syncing, the folder will have the same modified date and creation date, on both sides. The folder is copied as is, all attributes. It doesn't however, keep the modified date in sync, since syncing only overwrites/syncs files and not the folder itself.
When a file changes and is compared by modified date, the file is copied over and overwrites the older one. When a folder's contents changes, its date modified changes and then what? you can't just simply re-copy the folder like you do with files because the folder is already there, and if that is done all files will be overwritten all over again. Should it just copy the date modified attribute on a folder that had its files changed? It already made changes to the files within the folder and hence why the modified date changed on the folder to the date you did the sync. A folder is created just once and both dates are preserved since it is well a "creation" and attributes are copied over, files however, are always changing and are copied over/overwritten, an overwrite is a "creation" and all attributes go with it all, just like with a folder's first sync. When you sync files, you are either overwriting or deleting what doesn't exist. Renames do not change the date modified attribute hence, why they simply are always in sync during renames.
FFS compares files themselves, it looks at the file level, it doesn't really compare folder modified date, just whether it exists or not. It doesn't take folders attributes as a syncing object unless the folder doesn't exist on one of the sides or it had its name changed, since files by themselves indicate what needs to be synced. It doesn't scan and say "hey this folder changed, lets sync the files or lets overwrite the entire folder again". It looks at the files and simply syncs the files, since the folders attributes have no use in the syncing process.
It is possible to copy just the attribute, and it is rather simple. The complex part would be using folders as a syncing object. They would have to now be considered each time whether or not a file is compared. I guess this would lengthen the scan process quite a bit, since now, you would have to check thousands of folders and compare them. Or, should they just be considered only for the detected changed file's root directory? E.g: if a file changes in c:\a\ and not in c:\b\ ignore modified date comparison of b and just do a?
In summary, folder attributes have no use in the comparison algorithm since the files are the ones that dictate what transfers over. Both creation date and modified date are synced on an initial sync because it is a new creation. The creation date of folders is retained always since folders are only created once, and then have their file contents modified which are the ones being edited. Only when a folder is deleted or renamed it is actually considered since now the "table" of changes has had an entry added, removed, or edited. It is the nature of the beast, since files and folders only keep the dates when copied and recreated new or overwritten. For FFS to keep the modified date the same just as it does with files, it would have to recopy and overwrite the entire folder as a "whole". But since it doesn't do that, and instead syncs the "content" that changed, it needs to be copied manually some other way.sfxs
The other thing, much more important in my mind, is that every subfolder has its modify date reset on the initial creation when new files are added, per the explanation, which makes perfect sense. However, if, at the end of the session, you were to reset the modify date of any newly created folder to match the source, that would really work out perfect.
I love the program and I can live with the above, but I just thought I'd offer a little more info and a suggestion.
- Posts: 1
- Joined: 5 Sep 2015
I found this "feautre" too. Not only times, but directory attributes & permissions / ACLs are not synced if they have changed. This stops me using FFS for my usage :(
I really like to see robocopy like feature to have option to sync directory times and another to sync all directory permissions.
Offtopic: I would also like to see compare and sync as one transaction under windows VSS. Now you can end up with broken copy if only some files change between compare operation and sync.
I really like to see robocopy like feature to have option to sync directory times and another to sync all directory permissions.
Offtopic: I would also like to see compare and sync as one transaction under windows VSS. Now you can end up with broken copy if only some files change between compare operation and sync.
- Posts: 1
- Joined: 6 Sep 2015
It is convenient to have the folder ModifiedDate set to CreatedDate. I am hoping option will be included in the next release. In the meantime I used Attribute Changer to effect this change on my NAS, updating Modified Date to Created Date. In AC you can right-click on the various date/time fields for advanced options. I found 'basic' mode to be useful here as well.
- Posts: 18
- Joined: 7 Dec 2001
I also need the ability to sync times and dacl information on subsequent changes using FFS in order to make it a "true" robocopy replacement for my usage.I found this "feautre" too. Not only times, but directory attributes & permissions / ACLs are not synced if they have changed. This stops me using FFS for my usage :(
I really like to see robocopy like feature to have option to sync directory times and another to sync all directory permissions.
Offtopic: I would also like to see compare and sync as one transaction under windows VSS. Now you can end up with broken copy if only some files change between compare operation and sync.jjmaline
- Posts: 18
- Joined: 7 Jan 2001
+1 vote to preserve dates and times of directories (very important).
+1 vote preserving ACLs.
+1 vote preserving ACLs.
- Posts: 18
- Joined: 7 Dec 2001
Consider making a donation to the project as a bit of a "bounty". I did so and indicated the ACL issue was important to me and this does seem to have gotten some notice by the developer. Perhaps some additional donations will bring this sooner rather than later?+1 vote to preserve dates and times of directories (very important).
+1 vote preserving ACLs.webmaster33
- Posts: 1
- Joined: 12 Aug 2016
Are there still plans to include a feature to go back and reset each directory's "Date Modified" field after a sync process?? I'm currently using robocopy's "/TIMFIX /XF *" options to go back and fix the dates after a sync in FFS... Would be awesome if FFS would include this option for future releases..
- Posts: 1
- Joined: 19 Oct 2016
Any news about this feature? I`ve liked the program, but the absence of so necessary option stops me from using FFS.
- Posts: 1038
- Joined: 8 May 2006
(I'll just point out, for Windows users, Nirsoft's FolderTimeUpdate is a simple tool for Windows that scans all files and folders under the base folder you choose, and updates the 'Modified Time' of every folder according the latest modified time of the files stored in it.
This tool might be useful if, for example, you backup a cluster of folders and then restore them into another disk, but the backup program doesn't restore the original modified time of the folders.)
This tool might be useful if, for example, you backup a cluster of folders and then restore them into another disk, but the backup program doesn't restore the original modified time of the folders.)
- Posts: 1
- Joined: 27 Oct 2016
I agree, at the end of the session the FFS can go back and reset the folder dates and times to their originals - This is EXACTLY what directory OPUS does optionally. I too would love to see this implemented as it is the only thing stopping me from completely adopting FFS.Your explanation makes sense, but a couple of additional thoughts here. First, each top level folder in the folder pairs has the modify date changed every time the sync is run, regardless of whether any changes are made or not. That's because of the "sync.ffs_lock" that gets updated in the folder. So this is one thing that is a bit of a "false positive" on the time stamp. This one is minor, but potentially something that could be addressed.
The other thing, much more important in my mind, is that every subfolder has its modify date reset on the initial creation when new files are added, per the explanation, which makes perfect sense. However, if, at the end of the session, you were to reset the modify date of any newly created folder to match the source, that would really work out perfect.
I love the program and I can live with the above, but I just thought I'd offer a little more info and a suggestion.doncaruana
If therer are there are any developers reading this thread, could you kindly give us an update as to whether this feature is being looked at or will be implemented?
Thank you for listening.
- Posts: 3
- Joined: 25 Aug 2019
+ 1 on this feature and an update to the thread. I love the tool for migrating tons (30TB+) to new servers in rapid fashion, but would love having the folder modify date sync as well. I am testing the Nirsoft tool as my users will flip out if folder mod dates do not reflect the mod dates on current servers.
-
- Posts: 67
- Joined: 7 Dec 2016
Hi all,
> my users will flip out if folder mod dates [are changed]
I have the same problem here after restoring a folder structure on a network drive using FreeFileSync.
Is there any new status on this feature request, or on a workaround/fix?
Thanks!
> my users will flip out if folder mod dates [are changed]
I have the same problem here after restoring a folder structure on a network drive using FreeFileSync.
Is there any new status on this feature request, or on a workaround/fix?
Thanks!
-
- Posts: 67
- Joined: 7 Dec 2016
I just tried the incredibly ingenious tool Nirsoft FolderTimeUpdate from further above in the thread on a temporary, local copy of my file server. It worked great in resetting the folder dates to the date of the file(s) in the folder. I think the users will certainly be satisfied with this.
Any reason not to run the tool on the actual file server (locally mounted via a Windows drive letter) now?
Is the tool safe in order that nothing can go wrong, e.g. deleting folders or files, or creating duplicates?
Thanks for any experience or advice!
Any reason not to run the tool on the actual file server (locally mounted via a Windows drive letter) now?
Is the tool safe in order that nothing can go wrong, e.g. deleting folders or files, or creating duplicates?
Thanks for any experience or advice!
- Posts: 3
- Joined: 25 Aug 2019
I used the Nirsoft tool directly on my server prior to cutover in September with no issues (no deleted or duplicative files/folders) and no grumbling from users post-cutover. My largest folder tree was about 9TB and ~9m files/folders) and folder dates mods completed in a few hours.
I did run scan mode to review changes and see that they were pretty much in sync. Be aware that if a user copies a older file to a folder, the original folder will reflect the date of the activity, not necessarily a "last file date" of files in the folder. Fortunately, in most cases, files are put in folders shortly after creation, so not a huge risk if the folder mod timestamp is off by a few minutes.
I did run scan mode to review changes and see that they were pretty much in sync. Be aware that if a user copies a older file to a folder, the original folder will reflect the date of the activity, not necessarily a "last file date" of files in the folder. Fortunately, in most cases, files are put in folders shortly after creation, so not a huge risk if the folder mod timestamp is off by a few minutes.
-
- Posts: 67
- Joined: 7 Dec 2016
Thank you for sharing your experience!
> Be aware that if a user copies a older file to a folder, the original [?] folder will reflect the date of the activity
Why do you think is that so? The Nirsoft tool should use the modified time of files in the folder:
So, if a user copies an older file to a folder, that file's modified date should not change, and the folder's modified date should still reflect the youngest file in that folder, not the user's activity time, shouldn't it?
> Be aware that if a user copies a older file to a folder, the original [?] folder will reflect the date of the activity
Why do you think is that so? The Nirsoft tool should use the modified time of files in the folder:
So, if a user copies an older file to a folder, that file's modified date should not change, and the folder's modified date should still reflect the youngest file in that folder, not the user's activity time, shouldn't it?
-
- Posts: 67
- Joined: 7 Dec 2016
I just realized that our folders typically contain mostly MSG files whose last modified date typically doesn't change because they are never edited.
So by restricting the re-dating of the folders based on MSG files only, chances are that the results will be very good, and very close to the actual original Folder creation date.
Correct?
So by restricting the re-dating of the folders based on MSG files only, chances are that the results will be very good, and very close to the actual original Folder creation date.
Correct?
-
- Posts: 67
- Joined: 7 Dec 2016
After thinking about that for a minute: why doesn't it update the modified time on the folder according to the earliest modified time of the files stored in it?Nirsoft's FolderTimeUpdate is a simple tool for Windows that scans all files and folders under the base folder you choose, and updates the 'Modified Time' of every folder according the latest modified time of the files stored in it. therube, 19 Oct 2016, 23:32
Wouldn't that make much more sense because the folder obviously must have been created shortly before the first file went into it, and not shortly before the last File went into it.
- Posts: 3
- Joined: 25 Aug 2019
I took a look at one of the servers I migrated using FFS in the fall. The create date attribute of destination migrated folders was maintained from the source using FFS. Nirsoft's FolderTimeUpdate will only change the last mod time of the folder based on the timestamp of the latest file in the folder. So maybe you're good if create date, rather than mod date is your focus.
-
- Posts: 67
- Joined: 7 Dec 2016
Thanks! I actually never paid much attention to folder dates really.
Is it normal Windows (Explorer) behavior that the folders always seem to show a modification date equal to the latest modification date that a file inside that folder has?
(I believe that folder creation date is normally not shown anyway)
Is it normal Windows (Explorer) behavior that the folders always seem to show a modification date equal to the latest modification date that a file inside that folder has?
(I believe that folder creation date is normally not shown anyway)
- Posts: 11
- Joined: 3 Sep 2020
This thread was linked from a (duplicate) post I made a couple of days ago. I'd like to add my 2c that the importance of modified dates in folders has to do with indexing/sorting and search functions. If I'm looking for something with Spotlight, it pays attention to these modified folder dates. That is the primary criteria I use when looking for something of relevance. If these folders all have modified dates that correspond to the latest sync date, it means they are all potentially now "MOST RELEVANT" to whatever search matches one of them. It's a lot of false positives to ignore with massive folder trees like what I am currently shifting from drive to drive.
Also, in a practical case, I am having to migrate data from a NAS array to local distributed storage only for the purpose of re-creating the RAID array on the NAS and moving the data right back. This process will irrevocably destroy the modified folder attributes unless a fix is implemented. That will have some significant downsides for me.
Nirsoft FTU is a great solution, but I'll have to run it in a VM to make that work, and hooking everything up to the VM will be a bit tricky. Not sure if I want to embark on that journey just yet. I would much rather have this wonderfully cross-platform application handle the mess in stride. :-)
Also, in a practical case, I am having to migrate data from a NAS array to local distributed storage only for the purpose of re-creating the RAID array on the NAS and moving the data right back. This process will irrevocably destroy the modified folder attributes unless a fix is implemented. That will have some significant downsides for me.
Nirsoft FTU is a great solution, but I'll have to run it in a VM to make that work, and hooking everything up to the VM will be a bit tricky. Not sure if I want to embark on that journey just yet. I would much rather have this wonderfully cross-platform application handle the mess in stride. :-)
- Posts: 8
- Joined: 31 Jan 2022
I tried the Nirsoft FolderTimeUpdate tool mentioned earlier. It worked great and it was pretty quick on about 900 folders. But I have to agree it would be a whole lot better if it worked within FreeFileSync.
See: https://www.nirsoft.net/utils/folder_time_update.html
I keep client and job folders, a couple thousand of them. Being able to sort them by date is very important to me. Losing those dates was devastating, when I backed them all up to a new directory.
See: https://www.nirsoft.net/utils/folder_time_update.html
I keep client and job folders, a couple thousand of them. Being able to sort them by date is very important to me. Losing those dates was devastating, when I backed them all up to a new directory.
- Posts: 1038
- Joined: 8 May 2006
+1But I have to agree it would be a whole lot better if it worked within FreeFileSync.
+2
+3... :-).
- Posts: 2
- Joined: 18 Feb 2022
+4...
the use of the external Nirsoft tool is a lightly suboptimal solution, (double effort for two progs, practicable only use of cli-scripts..)
I would suggest to implement the easy way of changing the modifiction date of dirs
- at the start of a new sync, store the modification date of the source-dir in memory
- sync all files within this dir, as usual
- at the end of this operation, change the modification date of the destination-dir to the date in memory
thats the pragmatic way. It doesn't need a complicate evaluation of all dir-dates in alls subdirs..
Its sufficient to make the dir-attributes from the destination to the same as the source ones.
windows itself often doesn't have the correct mod-date of dirs.
the use of the external Nirsoft tool is a lightly suboptimal solution, (double effort for two progs, practicable only use of cli-scripts..)
I would suggest to implement the easy way of changing the modifiction date of dirs
- at the start of a new sync, store the modification date of the source-dir in memory
- sync all files within this dir, as usual
- at the end of this operation, change the modification date of the destination-dir to the date in memory
thats the pragmatic way. It doesn't need a complicate evaluation of all dir-dates in alls subdirs..
Its sufficient to make the dir-attributes from the destination to the same as the source ones.
windows itself often doesn't have the correct mod-date of dirs.
-
- Posts: 2453
- Joined: 22 Aug 2012
You can discuss as much as you want.
Instead of re-inventing the wheel, (at least the Windows version of) FFS uses the standard Windows routine (the same one as used by Windows File Explorer) for copying files and folders, in which copied over folders will have a date/time as per the moment of copying.
See also here.
Instead of re-inventing the wheel, (at least the Windows version of) FFS uses the standard Windows routine (the same one as used by Windows File Explorer) for copying files and folders, in which copied over folders will have a date/time as per the moment of copying.
See also here.
-
- Site Admin
- Posts: 7212
- Joined: 9 Dec 2007
The problem isn't exactly the copying routine, it's more fundamental: When a file is created/deleted it changes the parent folder's modification time. This means fulfilling the requirement of copying folder modification times would necessitate (1) an additional pass over all folders at the end of sync. (2) This is further complicated by the fact that folder modification times are often not supported, thous have the potential of creating a "never in sync" situation.You can discuss as much as you want.
Instead of re-inventing the wheel, (at least the Windows version of) FFS uses the standard Windows routine (the same one as used by Windows File Explorer) for copying files and folders, in which copied over folders will have a date/time as per the moment of copying.
See also here. Plerry, 20 Feb 2022, 15:39
- Posts: 8
- Joined: 31 Jan 2022
@ Zenju: I can understand that. By the way, thanks for such a great product!
The Nirsoft solution is just fine with me. Very fast and I can add it to the end of my batch FFS runs for the folders that need accurate dates. It can be run from a batch file as well as the GUI. The nirsoft page provides a table of the various options.
I eliminate the never in sync issue by also running the Nirsoft folder time against the source folder as well, because FolderTime sets the folder dates to oldest file date within the folder -- which may not match the original folder date.
The Nirsoft solution is just fine with me. Very fast and I can add it to the end of my batch FFS runs for the folders that need accurate dates. It can be run from a batch file as well as the GUI. The nirsoft page provides a table of the various options.
I eliminate the never in sync issue by also running the Nirsoft folder time against the source folder as well, because FolderTime sets the folder dates to oldest file date within the folder -- which may not match the original folder date.
- Posts: 2
- Joined: 18 Feb 2022
@Plerry: ist not a re-invention of the wheel. Please understand whats the problem is. To use the explorer integrated routines are a crap.(limited to 255 chars since NT4, modifcation date is often not correct for dirs including a lot of subdirs f.e.)You can discuss as much as you want.
Instead of re-inventing the wheel, (at least the Windows version of) FFS uses the standard Windows routine (the same one as used by Windows File Explorer) for copying files and folders, in which copied over folders will have a date/time as per the moment of copying.
See also here. Plerry, 20 Feb 2022, 15:39
for that reason tools like totalcommander (ghisler.com) have implemented aditional routines for copying folders. There is an extra option to configure that behavior.
And yes, TC uses the standard explorer routines.
It cannot be too much effort to implement these option into ffs.
- Attachments
-
- Total commander directory copy option
- TC-Copy_delete-options.jpg (406.71 KiB) Viewed 7938 times
- Posts: 3
- Joined: 10 Jul 2022
Heya. New user. Liked what I saw so much I bought FreeFileSync before testing much. Then I noticed it discards folder dates...
I can't currently speak to #2.
M-oster raises an excellent point about this feature being implemented in other software. Try to make it an option in FreeFileSync, please. It's unfortunate your users are having to worry about cobbling together kludgy third-party script band-aids to work around this feature omission.
Other than that, thank you for the useful, capable app.
Unfortunately I made my donation before noticing FreeFileSync was destroying folder metadata, so won't have the opportunity to weigh in via that avenue. I'll at least do so here, though:Consider making a donation to the project as a bit of a "bounty". I did so and indicated the ACL issue was important to me and this does seem to have gotten some notice by the developer. Perhaps some additional donations will bring this sooner rather than later? greydawn, 05 Oct 2015, 21:06+1 vote to preserve dates and times of directories (very important).
+1 vote preserving ACLs.webmaster33
Taking longer to achieve the result I need / expect here is fine. I just need the result.This means fulfilling the requirement of copying folder modification times would necessitate (1) an additional pass over all folders at the end of sync. (2) This is further complicated by the fact that folder modification times are often not supported, thous have the potential of creating a "never in sync" situation. Zenju, 20 Feb 2022, 17:14
I can't currently speak to #2.
M-oster raises an excellent point about this feature being implemented in other software. Try to make it an option in FreeFileSync, please. It's unfortunate your users are having to worry about cobbling together kludgy third-party script band-aids to work around this feature omission.
Other than that, thank you for the useful, capable app.
