Successful upload shows Red filenames

[Michael Bulgrien]

After uploading a file to an FTP site, the CRC, date, and size show the same on both sides, but the filenames are red as if the files differ from each other:

This only occurs if the initial hard drive to FTP site compare is still in process when the file is uploaded.
If the initial compare is complete, the uploaded file correctly turns black once the upload completes.

[Chris]

Michael,

Thanks for posting the bug report. What background comparison type are you using in your screen shot? Is it CRC, binary, or rules-based? Does the problem show up regardless of the content comparison type?

[Michael Bulgrien]

I use size and CRC comparisons. I have not tried with other comparison types.

[Chris]

Michael,

Thanks for describing this bug. I haven't been able to repeat this myself, but I discussed it with my coworker Craig, and he found a potential timing issue in the code for this. Craig said he'll work to improve the behavior.

[Zoë]

Michael,

I've figured out where the timing issue is and we'll try to get it fixed soon. We haven't been able to repeat it in-house yet, but theoretically the bug affects all three content comparison types.

[dickdunbar]

I reported a similar issues with uploading, just not in the forums.

1. It would appear that some ftp servers aren't capable of setting (touching) the correct date on an upload, so the timestamps are always out of whack. "crc" is the only choice here, but that involves quite a lot of processing. crc on the ftp site could only be achieved by actually uploading the file ... is there another way you're achieving this?

2. a gif file is binary. Most of my ftp transfers involve text files, and the ftp "ascii" option correctly modifies the Windows CR/LF line endings with "LF" on the unix ftp site.
So they always mis-compare, even with (especially with) crc.

Solution: Always upload in binary and "deal with it".
- A unix line-ending aware editor on the windows side
- Windows line-ending programs on the unix side.

Windows CR/LF won't work with shell scripts, because the magic first line is
doesn't correctly identify the shell pgm:
#!/bin/sh^M

I can only admire the problem. No convenient suggestions in mind.

[Zoë]

Dick,

1) Cirrus has a "touch local files when uploading" (or something similar) option in the Session settings, which will keep the local files in sync with the ones on the FTP server if touching the remote files doesn't work. If you're able to use it it's a decent alternative. If you have to use CRCs, some FTP servers support the XCRC command, which computes the CRCs on the server side rather than requiring BC to download the files first. For servers that don't support that we do have to download the files.

2) You've summed up the situation pretty well. I'd love to make binary transfers the default to ease support, but that would probably affect people just as adversely as the current behavior. About the only other solution we're thinking of right now is saving the comparison results for all the files in a session as sort of a extended snapshot, so binary comparisons will only have to occur for files that were changed from the last time it was run. Technically the SFTP protocol says that server-side hash calculations (equivalent to FTP's XCRC) should be done using the current transfer type, which would help, but I don't think there are any SFTP servers that actually implement server-side hashes now, let alone with that enhancement.

[Marjolein Katsma]

Solution: Always upload in binary and "deal with it".
- A unix line-ending aware editor on the windows side
- Windows line-ending programs on the unix side.

Lots of Windows-based editors actually support Unix line endings - I've been using Unix line endings as standard for many years, and usually set up all my FTP programs to just upload as binary. Some editors that support Unix ine endings are light-weight (but very capable) Crimson editor (freeware), UltraEdit (shareware), and Eclipse (FOSS) - I use all three depending on task.

As an alternative, Cirrus itself supports changing line endings, so if your common editing environment doesn't support Unix line endings, you could still use Cirrus to convert your files before uploading (as binary).

[dickdunbar]

I forgot about this thread; I do have a way to deal with timestamps:

Use "sftp", not "ftp" ... it provides the capability to set timestamps correctly.
"Touch" also behaves correctly on the ftp side to reset timestamps.

Previously, my ftp uploads were stamped with current time ....
and I used "Touch" on the local folders to keep them in sync.

Didn't like that very much ... I need accurate timestamps to keep track
of things ... especially source code.

I reported a similar issues with uploading, just not in the forums.

1. It would appear that some ftp servers aren't capable of setting (touching) the correct date on an upload
No convenient suggestions in mind.