Hi Zenju,
Thanks for all your help with everything so far.
Along with using FFS at work, I have decided that it would also be great to
use for a personal application. My band and I happen to use a lot of
electronic files and need a way for file collaboration. Currently, we are
using Dropbox, but have run out of (free) space. I was thinking I could create
something similar to Dropbox using FFS and an FTP site.
First, I wanted to ask about the potential addition of a feature having to do
with conflicts. One thing we have run into quite often is that two people have
edited the same file (the local copies on each of their machines) at the same
time, or maybe at different times, but one (or both of them) was disconnected
from the internet. When DB syncs and notices these conflicts, one of the files
that is in conflict (I'm guessing the one with the earlier timestamp?) is
renamed from: "Example.txt" to something like: "Example (%computer name%'s
conflicting version).txt". I like this method a lot because next time one of
us would go to open "Example.txt" we would see both of these and then either
get contact with the other person to see what they changed, or just open and
compare the two files to see what the difference is. Currently in FFS, I do
not think this can be achieved (unless maybe through some crafty batch file?).
The only options that I know of are to set FFS to do nothing when a conflict
occurs, but then, not everyone will have the same copy of the file, which is
no good. The other option is to just sync the latest file, but then all the
work that was done on the file on the other guys computer that was saved
earlier would now be overwritten with the new file, which is also un-ideal. So
unless i missed some other way to achieve this (which is very possible!) I was
wondering if an option could be made available so that is a conflict was
found, the 2 (or potentially even more than 2) files would all be synced, with
some method of renaming the conflicts.
Second...the FTP. DB also sync's the files to the cloud (I hope I'm not
sounding like a DB fanboy, I really do appreciate your awesome work on FFS,
and would rather use it then DB), which is convenient if you are not at your
personal machine when you need access to a file). So i decided to set up an
FTP site which will serve 2 purposes. It will be the means by which each of my
band mates connect to each other (I change file => syncs to FTP => band mates
folders sync changes made to FTP). Also, the FTP itself will be accessible
from anywhere with an internet connection, so it will be like the "cloud sync"
feature of DB.
So I downloaded NetDrive, and tested it with my laptop and desktop. I had a
test folder on each computer, along with the mapped FTP location that was
being monitored with RTS. When I make a change to a local folder on, say, the
desktop computer (like adding a new file), the change will be synced to the
FTP. If I refresh my explorer window on the desktop computer that is open to
the mapped FTP, I see the new file appear in there. If I do the same on the
laptop, I also see the new file appear. However, the change never gets sync'd
to the local folder on my laptop, almost as if RTS does not notice a change to
the FTP for some reason. If I double click the RTS icon in the system tray,
and then press "Start" on the dialog, (basically forcing a manual sync), the
change will finally be sync'd to the local folder. The same problem happened
when I reversed the whole process I just described above (i.e. made change on
the laptop first). Is this an issue with RTS, or am I doing something wrong?
Lastly, I read the help file section about the FTP timestamp problem (along
with this post: viewtopic.php?t=972 I noticed how you said "Most FTP drives" have
this is issue (in the help file), and something similar in the post. So I'm
guess that some actually can preserve timestamps? I was wondering if you had
any experience with FTP's, and if so, do you know any that allow the timestamp
to be preserved? (The one I currently setup is just using the built-in Windows
7 FTP server). I'm just starting out on web servers and FTP's so any advice
would be greatly appreciated.
Thanks so much!
Rename Conflicts & FTP help
- Posts: 10
- Joined: 19 Sep 2011
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
> potential addition of a feature having to do with conflicts.
FFS's current conflict handling will mark the respective rows as such and
notifiy the user when he starts synchronization at the latest, that
"unresolved" conflicts are existing. So he has three options now, ignore the
conflict, which will do nothing, so that he can resolve the conflict next
time, or manually inspect both files and set a direction, or resolve the
conflict externally. I'm not sure if the alternate handling of copying the
conflicting files on each others side under a different name adds a
significant benefit that justifies its own GUI option.
> FFS, and would rather use it then DB
Well, I'm also using Dropbox... it's not that FFS and DB would be exclusive :)
> almost as if RTS does not notice a change to the FTP for some reason
I'm using the standard Windows API for monitoring directory changes. Although
I accurately check and propagate all errors, it is quite possible that
Netdrive doesn't support monitoring and incorrectly does not report errors.
Unfortunately it's not surprising to see implementations that do not support a
particular feature and simply pretend "all is well" when checking for error
codes. (Or worse, report total nonsense, e.g. some readonly FTP drives report
"file already existing" when trying to write-access it.)
Depending on how current your data needs to be, a more robust approach would
be to sync the data twice, once on system startup and once on shutdown.
>know any that allow the timestamp to be preserved
I'd just check and see. Legacy FTP used to not support modification times. But
were 2011 and there should be enough providers now, that do.
FFS's current conflict handling will mark the respective rows as such and
notifiy the user when he starts synchronization at the latest, that
"unresolved" conflicts are existing. So he has three options now, ignore the
conflict, which will do nothing, so that he can resolve the conflict next
time, or manually inspect both files and set a direction, or resolve the
conflict externally. I'm not sure if the alternate handling of copying the
conflicting files on each others side under a different name adds a
significant benefit that justifies its own GUI option.
> FFS, and would rather use it then DB
Well, I'm also using Dropbox... it's not that FFS and DB would be exclusive :)
> almost as if RTS does not notice a change to the FTP for some reason
I'm using the standard Windows API for monitoring directory changes. Although
I accurately check and propagate all errors, it is quite possible that
Netdrive doesn't support monitoring and incorrectly does not report errors.
Unfortunately it's not surprising to see implementations that do not support a
particular feature and simply pretend "all is well" when checking for error
codes. (Or worse, report total nonsense, e.g. some readonly FTP drives report
"file already existing" when trying to write-access it.)
Depending on how current your data needs to be, a more robust approach would
be to sync the data twice, once on system startup and once on shutdown.
>know any that allow the timestamp to be preserved
I'd just check and see. Legacy FTP used to not support modification times. But
were 2011 and there should be enough providers now, that do.
- Posts: 10
- Joined: 19 Sep 2011
Zenju,
>I'm not sure if the alternate handling of copying the conflicting files on
each others side under a different name adds a significant benefit that
justifies its own GUI option.
So does this mean that FFS could still accomplish this with a non-GUI
approach, say, using a batch file? If so, that would be fine, just as long as
there is some way to accomplish what I’m after, even if it’s a non-GUI
approach. Personally, I find this ability to be very important, so that the
user is not bogged down with a dialog that requires his or her attention every
time there is a conflict. Your current syncing methods do address avoiding
prompting the user most of the time, but in collaboration applications
(versus, say a like just within a home network), I think there needs to be way
that every user can see what the conflict is, by having both files to look at
right in the folder.
Maybe I’m trying to do something that RTS wasn’t designed for, but my plans
are that, after the required initial configuration, RTS will run in the
“background” (I’ll probably even set it to run as a service) keeping all
folders in sync, without needing any user input. While the feature I’m
suggesting would still require the user to manually check the two files and
make a decision on which file they need to keep, they would never have to deal
with RTS or FFS upfront. When accessing the conflicted file next time, they
would notice a conflict at the time of opening it (due to a file with a
similar name appaering directly before or after it), and then just take action
in the familiar environment of Windows explorer, by deleting the file they
choose is not necessary.
Okay I’m done. Sorry if my ramblings annoyed you (once again, you’re work is
much appreciated). But maybe I convinced you of the usefulness????? :D Just
thinking along the line of the K.I.S.S. philosophy (Keep It Simple
Stupid....for the user, that is haha).
Just an FYI, I decided to forgo the FTP server and am now using OpenVPN to
network all our computers together so that we can sync via a network share
from my desktop.
Thanks,
Michael
>I'm not sure if the alternate handling of copying the conflicting files on
each others side under a different name adds a significant benefit that
justifies its own GUI option.
So does this mean that FFS could still accomplish this with a non-GUI
approach, say, using a batch file? If so, that would be fine, just as long as
there is some way to accomplish what I’m after, even if it’s a non-GUI
approach. Personally, I find this ability to be very important, so that the
user is not bogged down with a dialog that requires his or her attention every
time there is a conflict. Your current syncing methods do address avoiding
prompting the user most of the time, but in collaboration applications
(versus, say a like just within a home network), I think there needs to be way
that every user can see what the conflict is, by having both files to look at
right in the folder.
Maybe I’m trying to do something that RTS wasn’t designed for, but my plans
are that, after the required initial configuration, RTS will run in the
“background” (I’ll probably even set it to run as a service) keeping all
folders in sync, without needing any user input. While the feature I’m
suggesting would still require the user to manually check the two files and
make a decision on which file they need to keep, they would never have to deal
with RTS or FFS upfront. When accessing the conflicted file next time, they
would notice a conflict at the time of opening it (due to a file with a
similar name appaering directly before or after it), and then just take action
in the familiar environment of Windows explorer, by deleting the file they
choose is not necessary.
Okay I’m done. Sorry if my ramblings annoyed you (once again, you’re work is
much appreciated). But maybe I convinced you of the usefulness????? :D Just
thinking along the line of the K.I.S.S. philosophy (Keep It Simple
Stupid....for the user, that is haha).
Just an FYI, I decided to forgo the FTP server and am now using OpenVPN to
network all our computers together so that we can sync via a network share
from my desktop.
Thanks,
Michael
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
FreeFileSync supports SFTP directly as of version 7.2.