Problems with sync software: timestamps and non-latin chars

[pizzaman]

...as does superflexible by the way.

It seems as if Filezilla server, does return "last modified times" for the files i modified, but not for the other files (on the LIST command). Sigh, now i'm puzzled again...

[botg]

The ls -l style listings returned by LIST cannot carry both a year and a time column. It's either year or time. That's why you don't see a time for older files, it cannot be displayed without losing information on the date. Just on files recent enough time can be displayed.

[pizzaman]

Thanks, that explains a lot. I'm such a noob Then again, the person who invented this surely didn't have an overdose of wisdon either

Superflexible, from one second to the other, read non-latin characters without any problem . If they would have a portable version, i'd finally be able to synch from work to home. Until then, the cloud computing era hasn't begun quite yet for yours truly .

[botg]

The origins of the FTP protocol go back more than 30 years.

[www.milessampson.com]

Hello Pizzaman.
I have been a loyal support of AllwaySync for a long time now, but recently I decided to setup an FTP server so i could sync remotely and AllwaySync has just fallen flat on its face. I am trying out Super Flexible File Sync on some test folders, and it seems to be doing a much better job, so now I ran it on one of my main working folders (one that had been synced by AllwaySync). Before I tell it to do the Sync I was wondering about a few things:

• It is not working with non-latin charactors on the FTP side. It cannot seem to read them over the FTP connection. Is this another limitation of the FTP protocol? Although when i access the server using FileZilla client I can see all the non-latin characters fine
• Files that are over a certain age on the FTP side do not show the time stamps. As i understand it this is a limitation of the FTP protocal and SuperFlexiSync seems to be good at dealing with it. The only problem is when it comes to "daylight saving" and some files have an hour difference on the file stamp time. SuperFlexiSync can handle this on files too, except when the file was last saved after 11pm, so the one with an hour difference has the next days date and it does not have a time stamp because the file is on an FTP server and is too old. I guess once I have done a general sync, this will not be a problem anymore?
• For some reason a lot of my photos seem to have very small differences in times, say 2 or 3 minutes max. So SuperFlexiSync wants to update all these. AllwaySync was fine about these small differences in date for some reason.

My question to you is are you still using SuperFlexiSync and are you happy with the way it is preforming?

Thanks for your help.

[boco]

I'm not pizzaman, but I try a few points:

It is not working with non-latin characters on the FTP side. It cannot seem to read them over the FTP connection. Is this another limitation of the FTP protocol? Although when i access the server using FileZilla client I can see all the non-latin characters fine

When FTP was developed, the computer world spoke 7bit US-ASCII. I18n was not an issue then. Since then, there's only one official standardized extension to FTP dealing with the i18n problem: UTF-8. Both client and server must fully support it, FileZilla Client and Server do. But the sync software seems to have problems with it.
Note: Anything except 7bit US-ASCII and UTF-8 is not an official standard, there's no guarantee it will work.

Files that are over a certain age on the FTP side do not show the time stamps. As i understand it this is a limitation of the FTP protocal and SuperFlexiSync seems to be good at dealing with it

If the developers of the sync software would start using MLST/MLSD on servers supporting it, this would be a non-issue. MLSD always returns all information.

The only problem is when it comes to "daylight saving" and some files have an hour difference on the file stamp time.

Normally times in listings use GMT, but many servers return listings in local time. Doesn't work very well in practice. Maybe we should start a petition for banning DST from the face of earth.

[pizzaman]

Dear milessampson,

You've concluded, just as I did, that there are several issues, such as:
-non-latin characters
-systematic time differences (like dst)

For me, the only configuration that isn't plagued by any of them is:

Filezilla server
Version 9.33.
The only thing i change from the default settings is autoban and i give the user all access to the desired folder

Goodsync
8.x (i use the portable version)
UTF-8 on (now supported in goodsync!) and MDTM on, WinInet, active FTP off (see image)
Goodsync has a nice option to display a list of all the files with "Same length different time" to puzzle out what to do with these

Hope this works for you too!

[www.milessampson.com]

Thanks very much for all the help, I will keep you posted on how it works out.

[pizzaman]

Please do, i'm curious about your experience!

[www.milessampson.com]

OK, still experimenting, but what I did find is that when syncing over FTP is:
(a) you cannot have a space at the beginning of a filename, because it cannot read it.
(b) there is a limit to the length of the file, which I am still trying to establish what it is.

Thanks.

[pizzaman]

Late response, but i think it's 255 chars including folde names.

Filezilla server + goodsync still works. I backup between three pc's, my pda and have my parents and a friend auto-backup to my ftp server. All works like a charm...

[boco]

Late response, but i think it's 255 chars including folde names.

NTFS filesystem limit is ~65500 chars, but WinAPI limit is ~260 chars. This is for the complete path.