More impressions on an improving product

[dickdunbar]

I'm addicted to Cirrus/BC3. I have two other programs in this category that I also like very much, so these are suggestions toward creating the single/perfect program.

1. Free Download Manager
   http://www.freedownloadmanager.org/ Now open source
   
   FDP is not without its own minor quirks, but is pretty nearly perfect on the UI and Performance front.
   • Multiple concurrent downloads (like BC3)
   • Downloads are very fast because FDM uses multiple concurrent streams to download a single file. You can add/remove file segments on the fly.
   • Total download speeds (MB/Sec) is maintained, so you can see if you're making improvements in throughput.
   • Downloads can be interrupted, suspended, restarted, or lowered in priority to use less bandwidth
   
   Darn near perfect, but it misses the lovely directory compare services of BC3. What I want for BC3 is the same download speed and concurrency.
2. LapLink
   Similar services as BC3 for folder comparisons; BC3 is just more mature and elegant.
   
   What I'd like to see for BC3 is the ability to use specialized cables for the transfer, in addition to folder->folder and FTP.
   
   For example, WinVista has removed the functionality of an IEEE1394 (Firewire) network connection running at 400 and 800 Mbps. 1394 drivers are available on the web, and it would be a lovely addition to BC3 to be able to talk over a dedicated wire between two machines to synchronize them.
   

Usage observations in the last couple of days:

1. More concurrency in multiple copy requests
   I launched 17 distinct folder copy operations in a single tab, and observed that only one of them was running at a time. A large file transfer would block all of the smaller transfers.
   
   Using sysinternals procmon, I observed there was only 5 threads running, and only 1 devoted to handling all of the transfer activity.
   
   I would get better throughput if there was a dedicated thread handling each of the folder copies, each of which is independent.
   
   Clearly, one could overwhelm the system quite easily, so controls over the number of concurrent threads, and their relative priority (see FDM), might be needed.
   
   The beauty of the FDM approach to ftp transfers is that the handshaking delays between transmissions are completely buried, and the full bandwidth of the connection is exploited to produce more throughput.
   
2. Concurrent action bars should be in their own scrollable (middle) frame.
   Starting 17 concurrent folder copies means there are 17 progress bars in the middle frame, which reduces the visible space in the Folder View panel and the Log View panels. I think the middle panel should have it's own scroll window, so you can focus on what is important at the moment.
   
3. Ability to query multiple actions (hover)
   Once these 17 folders are being copied, there is no way to reveal what those copy actions are. Either that progress bar should contain some "folder" identification, or you should be able to "hover" over the bar to see what folder is involved.
   
   Reason: I have other copy actions to perform and I don't want to duplicate the work.
   
4. Show aggregate transfer rate
   Once downloads begin to overlap (instead of being scheduled in a single thread in a round-robin fashion), then aggregate data rate is important to see if you are making progress in order to suspend some threads, or introduce more folder copies.
   
5. Delete folder is now instantaneous
   Very nice improvement. Previously, moving a folder or deleting a folder caused BC3 to read the entire directory before performing the operation. Now it's faster than Windows Explorer. Nice.
   And, it works (almost as) fast on the unix ftp side too.
   
6. What is the "Finalizing" directory activity?
   After all the files are copied, I see some extensive activity in the Log window, while the middle window displays "Finalizing _folder_name".
   What is that?
   
7. After transferring source files from Windows to Unix, the -a (ascii) transmission must be in effect, because the resulting files on unix are now smaller than windows, and thus they don't compare (by size and date).
   
   If you using BC3 file compare, they show as equal ... but refresh the folders, and they are back to a non-compare state.
   
   Previously, I noted that the file date was not being set on unix; the file date was the time of transfer. To keep my sanity, I would use the "touch" option to reset timestamps on the windows side. That no longer serves my purpose of knowing which files are different, because of the ascii file differences noted above.
   
   No suggestions: I'm just admiring the problem.
8. More control over messages in the Log file using ftp
   I recognize the ftp messages, but they're mostly not needed so I'd like a way to filter them out of the Log pane. Thinks like "PASV", "opening data connect", "Entering passive mode", "CWD successful".
   
   I'd like to see just my file/folder transfer activity.

[Zoë]

Hey Dick,

1. More concurrency in multiple copy requests

Go into the Tools->FTP Profiles dialog, switch to the "Connection" tab and change the "Simultaneous Connections" setting. You may need to restart Cirrus to kick it. Cirrus doesn't split individual files up, but it will transfer multiple files in parallel.

2. Concurrent action bars should be in their own scrollable (middle) frame.

We'll consider that. Were you starting 17 transfers just to test Cirrus, or is that something you'd actually do regularly? You can select multiple folders and start them as a single copy...

3. Ability to query multiple actions (hover)

I'll add this to the bug list, but due to the way things are handled this may be difficult.

4. Show aggregate transfer rate

We'll see what we can do.

6. What is the "Finalizing" directory activity?

After copying to FTP sites Cirrus refreshes any affected directories to update the last modified time and size. If "Touch local files when uploading" is set (in the dir compare session settings), it touches the local source files after the refresh, and that's included in "Finalizing" too. I was hoping I could just keep the label generic, but you're the second person to ask, so we'll have to try getting more specific progress at that point.

7. After transferring source files from Windows to Unix, the -a (ascii) transmission must be in effect

You can adjust this in the FTP profile dialog too. It's on the "Transfer" tab as "Transfer Type". The default is "Auto", which uses ASCII or Binary based on the file's extension. Depending on your usage you may be able to use binary for all the files.

8. More control over messages in the Log file using ftp

Click on the gears icon on the left of the log to open the options dialog. You can uncheck "FTP trace" to disable FTP status messages.