I have a reproducable error with syncftpdir..

I have files with a name of aaa_20060201.txt(yesterday) with a timestamp of today (manually copied) on the LOCAL box

The remote box has files of aaa_20060202.txt (today) that will not transfer to the local box.

Usually, i sync with the top level of this directory, and this sub directory is caught in the sync with :
SyncFTPDIR "REMOTE", global.loc, global.user, global.pass, "/dir/subdir", targetfolder, true, false, true, true

I find myself not trusting the sync on different occasions.. dies this check via CRC values or ? My internet settings are set properly, and AFAIK all syncs have been fine up until this point.

It is based on parsing file listing returned by standard FTP commands, which depends on the time returned by your FTP server. In other words what you see in the console based FTP session reported by ls command is what 24x7 uses as a listing of the remote site, including names, dates, "dir" attributes and so on. AS you could see FTP protocol does not support CRC.

A bulletproof solution is not possible with FTP protocol for selective file synchronizing. Several alternatives are available. For example, you can delete all files from the target dir before running SyncFTPDir and then SyncFTPDir when run will FTP each and every file from the source. You can also map the source dir as a network share ad then use SyncLocalDir instead of SyncFTPDir.

: I have a reproducable error with syncftpdir..

: I have files with a name of aaa_20060201.txt(yesterday) with a timestamp of
: today (manually copied) on the LOCAL box

: The remote box has files of aaa_20060202.txt (today) that will not transfer
: to the local box.

: Usually, i sync with the top level of this directory, and this sub directory
: is caught in the sync with : SyncFTPDIR "REMOTE", global.loc,
: global.user, global.pass, "/dir/subdir", targetfolder, true,
: false, true, true

: I find myself not trusting the sync on different occasions.. dies this check
: via CRC values or ? My internet settings are set properly, and AFAIK all
: syncs have been fine up until this point.

I didn't think it was possible to map an FTP destination as a networked drive.

mapping a drive using ftp://xxxxx doesn't seem to work.

: It is based on parsing file listing returned by standard FTP commands, which
: depends on the time returned by your FTP server. In other words what you
: see in the console based FTP session reported by ls command is what 24x7
: uses as a listing of the remote site, including names, dates,
: "dir" attributes and so on. AS you could see FTP protocol does
: not support CRC.

: A bulletproof solution is not possible with FTP protocol for selective file
: synchronizing. Several alternatives are available. For example, you can
: delete all files from the target dir before running SyncFTPDir and then
: SyncFTPDir when run will FTP each and every file from the source. You can
: also map the source dir as a network share ad then use SyncLocalDir
: instead of SyncFTPDir.

Although it is possible in Windows Explorer on Windows 2000 and up to map an FTP URL as a network drive, I didn't mean that as it will be also bound by limitations of FTP protocol. What I meant is mapping the remote share as a regular network share using Samba or NFS gateway or other methods. Take a look at
http://support.microsoft.com/default.aspx?scid=kb;en-us;324087
http://compnetworking.about.com/od/softwareapplicationstools/l/aa062499.htm

: I didn't think it was possible to map an FTP destination as a networked
: drive.

: mapping a drive using ftp://xxxxx doesn't seem to work.