Attribute- and datetime-changes of existing folders are not recognized and so
not syncronized also.
Seems to be a bug or not yet implemented feature.
Is it possible to add this soon?
Attribute- and datetime-changes of folders.
- Posts: 26
- Joined: 19 Oct 2009
-
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
Currently this feature is not officially supported, although it is *partially*
working. When creating a new directory, attributes from source folder are
transferred, including hidden flag, NTFS compressed and NTFS encrypted flags.
However when comparing two directories FFS doesn't evaluate a directorie's
attributes and filetimes. Directories are associated by their name only, while
files are matched either by name, modification time and size or name and
content, depending on what comparison variant is set.
The reason for this behavior is that in contrast to files, a directory has
less *significant* metadata. Regarding attributes, the only relevant is the
"hidden" flag and for filetimes only creation and modification time are worth
noting. Modification time is changed each time a file is created or deleted,
which is somewhat redundant information, since the pure existence or
nonexistence of this file already says as much.
For a similar discussion regarding file attributes, see:
[404, Invalid URL: https://sourceforge.net/tracker/index.php?func=detail&aid=3175687&group_id=234430&atid=1093083]
working. When creating a new directory, attributes from source folder are
transferred, including hidden flag, NTFS compressed and NTFS encrypted flags.
However when comparing two directories FFS doesn't evaluate a directorie's
attributes and filetimes. Directories are associated by their name only, while
files are matched either by name, modification time and size or name and
content, depending on what comparison variant is set.
The reason for this behavior is that in contrast to files, a directory has
less *significant* metadata. Regarding attributes, the only relevant is the
"hidden" flag and for filetimes only creation and modification time are worth
noting. Modification time is changed each time a file is created or deleted,
which is somewhat redundant information, since the pure existence or
nonexistence of this file already says as much.
For a similar discussion regarding file attributes, see:
[404, Invalid URL: https://sourceforge.net/tracker/index.php?func=detail&aid=3175687&group_id=234430&atid=1093083]
- Posts: 26
- Joined: 19 Oct 2009
The reason why I ask for that feature ist that I will have to synchronize
subversion workfolders and also local subversion repositories.
They rely on folder-structures with own logic.
So if they decide to change something in these logics like any attribute
handling or other, I just wanna be sure to sync those stuff also.
Broken logics in those folders would be really a pain.
In the thread you pointed to, you wrote:
> It's not clear if changes in attributes alone should be detected and entail
synchronization.
Does this mean, that still, even in 4.0, attribute-only changes of existing
files are not regcognized/synchronized?
I didn't check this exclusively today, but only together with changing
timestamp values...
subversion workfolders and also local subversion repositories.
They rely on folder-structures with own logic.
So if they decide to change something in these logics like any attribute
handling or other, I just wanna be sure to sync those stuff also.
Broken logics in those folders would be really a pain.
In the thread you pointed to, you wrote:
> It's not clear if changes in attributes alone should be detected and entail
synchronization.
Does this mean, that still, even in 4.0, attribute-only changes of existing
files are not regcognized/synchronized?
I didn't check this exclusively today, but only together with changing
timestamp values...
- Posts: 26
- Joined: 19 Oct 2009
Additional post:
I checked explicitely now, if just changes of file-attributes are
detected/synchronized:
As you wrote, it is not.
Hm, sorry, in my opinion this would be necessary too.
I could live with a lower performance. Accuracy is more important to me.
To clear that: If a attribute change only is detected, the file itself must
not be synchronized. Only the attributes must.
But that would mean, that you store them in your DB-files too...
I checked explicitely now, if just changes of file-attributes are
detected/synchronized:
As you wrote, it is not.
Hm, sorry, in my opinion this would be necessary too.
I could live with a lower performance. Accuracy is more important to me.
To clear that: If a attribute change only is detected, the file itself must
not be synchronized. Only the attributes must.
But that would mean, that you store them in your DB-files too...
-
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
This isn't about performance. One has to distinguish files and folders:
For folders one has to consider most users probably don't care if folder
attributes have changed, so showing and synchronizing them would be a
nuissance.
Secondly there are drives that do not support folder attributes and filetimes.
It's not acceptable to show folders as different and not be able to
synchronize them. This will either lead to errors, or succeed, but show the
difference yet again after a new comparison (also consider read-only media
like DVD-Rom).
A third complication: Only when using automatic mode, or mirror it is possible
to determine a sync direction at all. There is no distinct category for
"different metadata" at least visible on GUI, so it would probably go under
"cannot categorize/conflict".
For files: All same issues as for folder apply. Additionally: In order to
determine for certain that two files differ in their metadata only (which
includes modification time), it is required to compare them binary. This is in
fact implemented: After a binary comparison FFS will offer to sync metadata
only, which includes modification time and filename "upper/lower case"
For folders one has to consider most users probably don't care if folder
attributes have changed, so showing and synchronizing them would be a
nuissance.
Secondly there are drives that do not support folder attributes and filetimes.
It's not acceptable to show folders as different and not be able to
synchronize them. This will either lead to errors, or succeed, but show the
difference yet again after a new comparison (also consider read-only media
like DVD-Rom).
A third complication: Only when using automatic mode, or mirror it is possible
to determine a sync direction at all. There is no distinct category for
"different metadata" at least visible on GUI, so it would probably go under
"cannot categorize/conflict".
For files: All same issues as for folder apply. Additionally: In order to
determine for certain that two files differ in their metadata only (which
includes modification time), it is required to compare them binary. This is in
fact implemented: After a binary comparison FFS will offer to sync metadata
only, which includes modification time and filename "upper/lower case"
- Posts: 1
- Joined: 20 Dec 2013
I'd love to rekindle this topic as I am a former SyncBack Pro user and have recently been exploring FreeFileSync. SyncBack Pro offers the option to "copy folder attributes and creation dates" (only when new directories are created) when possible. This option has been very valuable because many users (like me) with Windows (NTFS) file folders have custom (icon) attributes and folder properties, and currently all of them get discarded by FreeFileSync (along with the file creation date). SyncBack at least copies these initially when folders get created and so it works really well for the duplication of a directory structure on a new volume.
Is there anyway that this capability could be implemented in FreeFileSync? Superb program otherwise!
Is there anyway that this capability could be implemented in FreeFileSync? Superb program otherwise!
-
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
I've added copying folder creation and modification times upon first creation for the next FreeFileSync release. The rest, e.g. "custom (icon) attributes" should work already though: Just make sure that "desktop.ini" is not excluded.I'd love to rekindle this topic as I am a former SyncBack Pro user and have recently been exploring FreeFileSync. SyncBack Pro offers the option to "copy folder attributes and creation dates" (only when new directories are created) when possible. This option has been very valuable because many users (like me) with Windows (NTFS) file folders have custom (icon) attributes and folder properties, and currently all of them get discarded by FreeFileSync (along with the file creation date). SyncBack at least copies these initially when folders get created and so it works really well for the duplication of a directory structure on a new volume.
Is there anyway that this capability could be implemented in FreeFileSync? Superb program otherwise!jtbrown3
- Posts: 1
- Joined: 16 Sep 2015
To Zenju: This is only a half of true, because two changes are made when an icon of a folder is customized. Generation of a desktop.ini file is only one of them. The second change is setting of read-only attribute of the customized folder. Customized icon is not functional (visible) without read-only attribute set to folder. Current version of FFS copies desktop.ini file but does not change read-only attribute of an existing folder.
