Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
when i start a backup from drive d:\data to drive q:\data allways the same unchanged files are copied.
Even no chnages were made in the source.
Drive d: is a local drive and drive q: is mounted to a samba share.
Does anyone know about this problem?
this sounds like the program does not identify the source and destination to be in sync. it would help a lot if you could have a look at the size and lastmodified date of the files in the source and destination. after a successful sync they should be exactly the same. just test it with two or three files, if you got the time.
my assumption is that the samba server is not updating the lastmodified dates correctly so the files are always newer than the source (which actually means they are not in sync).
I have the same problem with a sftp server. If I execute the same profile a second time right after the first backup, Fullsync says that the source has changed and uploads each file again, although I have made no changes at all.
I have double checked by copying the files with winSCP which preserved the "changed date". But even after that Fullsync will upload all files saying the source has changed.
i've tested it with win-local -> win-smb and win-local -> linux-smb and it works both. i used fedora code 3, it would be nice if you could give me some details on the machines you use.
erm, you use publish/update with buffer ? the problem of ftp (and sftp) is that there is no way setting the change date AND the file sizes may differ because of ascii transfer (ok, at the moment everything is transferred binary). but to be honest, the second thing (copying using winscp) should work anyway if the program sets the dates correctly and there are mostly binary files.
so, if you use buffered publish/update already try to find out whether the problem only occures on ascii files (.txt, ...) otherwise... try buffered publish/update ;)
I used the option backup. I tried publish/update buffered now and now it works. What is the exact difference and why did it not work with backup? I am syncing word files only. Thanks for your help! Keep up the good work!
as stated above ftp and sftp protocols do not allow you to set last modified dates. that is why fullsync can't find out if the remote file is the same as the local one that easily. publish/update is the only sync mode which currently uses "buffering", say it uses a special file to store the lastmodified date and size of the files it stores on the remote site. this way it can find out whether local<->dst changed or dst changed at all (say dst buffer <-> real dst). erm... looks like this is not my best attempt to explain it ;).
ok, so, as far as i can think of at the moment the only difference should be that publish/updates will not overwrite files that changed remotely. as long as you know that this shouldn't happen it's ok i guess. i'll try building some more synchronisation types so you can use other types with buffering as well, like backup.
I'm having the same problem, though my profile is setup to use SFTP and the two-way sync type.
I have the same problem, I'm using XP SP1 and when I use it to sync a mapped drive (on a machine also running XP SP1) with a USB mass storage device (laptop HDD) it keeps wanting to add and delete files/folders.
I've tried replicating the problem and it seems to only want to add/remove certain files/folders. With some folders it doesn't happen at all, others it happens all the time.
Happens with all syncing modes
erm, you've got some special chars in those folders? like some german umlauts or whatever? there is a bug with that concerning ftp and sftp, but i can't really imagine it happens with win to win using smb (i guess).
it would be nice if you could look for some differences between folders that work and those who don't.
OK, I've fiddled around with it a bit and I think I found out what the problem was.
I had a folder that I renamed from "encryption" (in the source directory) to "ENCRYPTION". The problem was that when it detected the change in the name it then had to replace the old lower case folder with the upper case one. But the way it executed it was:
1. Create new "ENCRYPTION" folder
2. copy everything into it
3. Delete old "encryption" folder and everything in it (which for some reason deleted the "ENCRYPTION" folder)
This meant at the end of the sync it had deleted the folder again leaving nothing there. Then when I resynced again it detected there was no "ENCRYPTION" folder at all and copied it over.
I think you just need to reorder the process so all deletes occur first, then the adds happens after it.