First of all: Zenju, I am grateful to you for FFS, an incredibly
useful tool, with features even above commercial S/W! Surely deserves maximum
advertising...
---------------------
I'd like to ask you if you might add a feature to FFS which I would find
useful.
As of now, FFS compares the two directories by checking if a file exists in
one and doesn't exist in the other one or, if the file exists in both folders,
by checking if one is newer than the other.
File _SIZE _(or other file characteristics, like _OWNER, ATTRIBUTES, ACCESS
TIME, MODIFY TIME,_ etc...) are not taken into consideration.
It quite often happens to me that I have two directories including files with
the same name and timestamps, but in which size and/or owner/attributes/etc.
are different and there is no way to filter this situation with FFS.
Is there anything you can do?
Thanks in advance for everything!
Feature request: size/owner/attrib/.. filters
- Posts: 3
- Joined: 20 May 2011
-
- Site Admin
- Posts: 7210
- Joined: 9 Dec 2007
> File SIZE (or other file characteristics, like OWNER, ATTRIBUTES, ACCESS
TIME, MODIFY TIME, etc...) are not taken into consideration.
That's only partially true: File size and modification time are in fact
considered by the regular comparison method aptly named "compare by time and
size". Everything else would be ridiculous ;)
"Access time" isn't an important metadata (in the context of synchronization),
and I know of no scenarios one would want to synchronize it.
So what's left is "OWNER, ATTRIBUTES", where "owner" probably means all
security permissions, "owner" , "group", "dacl", "sacl".
Among the "attributes", the only one that may be interesting, and also only on
Windows Platforms, is "read-only".
This has been addressed here:
[404, Invalid URL: https://sourceforge.net/tracker/?func=detail&aid=3175687&group_id=234430&atid=1093083]
The problem with both attributes and permissions is, that they are not
universal concepts. They depend on the operating system (e.g. linux doesn't
have file attributes) and on the storage medium (Some read-only volumes have
the "read-only" attribute set on all files, which one most likely does NOT
want to sync to the other side. Other locations like cloud online storages,
don't support storing read-only at all. Security permissions are not supported
on FAT drives.)
The end of story would be to add a bunch of new options that are valid in only
limited scenarios and only to a limited number of users. This is some kind of
usability degregation FFS explicitly tries to avoid. This doesn't mean I only
concentrate on important concepts and features, but smaller features have to
prevail in the tradeof between "benefits" and "costs". Often this doesn't look
to good.
However if there is some way to integrate small features without any overhead
I'll gladly implement them (like for example FFS's detection of filenames
changin in case only).
-Zenju
TIME, MODIFY TIME, etc...) are not taken into consideration.
That's only partially true: File size and modification time are in fact
considered by the regular comparison method aptly named "compare by time and
size". Everything else would be ridiculous ;)
"Access time" isn't an important metadata (in the context of synchronization),
and I know of no scenarios one would want to synchronize it.
So what's left is "OWNER, ATTRIBUTES", where "owner" probably means all
security permissions, "owner" , "group", "dacl", "sacl".
Among the "attributes", the only one that may be interesting, and also only on
Windows Platforms, is "read-only".
This has been addressed here:
[404, Invalid URL: https://sourceforge.net/tracker/?func=detail&aid=3175687&group_id=234430&atid=1093083]
The problem with both attributes and permissions is, that they are not
universal concepts. They depend on the operating system (e.g. linux doesn't
have file attributes) and on the storage medium (Some read-only volumes have
the "read-only" attribute set on all files, which one most likely does NOT
want to sync to the other side. Other locations like cloud online storages,
don't support storing read-only at all. Security permissions are not supported
on FAT drives.)
The end of story would be to add a bunch of new options that are valid in only
limited scenarios and only to a limited number of users. This is some kind of
usability degregation FFS explicitly tries to avoid. This doesn't mean I only
concentrate on important concepts and features, but smaller features have to
prevail in the tradeof between "benefits" and "costs". Often this doesn't look
to good.
However if there is some way to integrate small features without any overhead
I'll gladly implement them (like for example FFS's detection of filenames
changin in case only).
-Zenju
