Improve folder monitoring by implementing delay

When a large file (~2GB) is copied to a folder being monitored by SmartFTP, it may upload several times. I have SmartFTP configured to use 5 upload threads. When a 2GB file is copied to the NAS folder being monitored, SmartFTP will detect the file and start an upload before the file copy is finished. The file then 'changes' as more of the file is copied, and SmartFTP will start a second upload.

I think this might be avoidable by waiting the monitored folder to stop changing before processing the monitored folder. The logic could be something like this:
Step 1: Wait for change in monitored folder
Step 2: Remember current state of monitored folder
Step 3: Wait 20 seconds
Step 4: Check for change in monitored folder since step 2, if changed, goto Step 2
Step 5: Process monitored folder according to rules

Something like this would allow SmartFTP to wait for large files to finish being copied to the monitored folder before starting the upload. It would then only upload 1 time instead of multiple times.


Duplicate transfer queue items should automatically be ignored. I will do some investigations why this is apparently not the case.

I'm on version 4.0.1135.0 (64-bit). I'm also forcing all files to lower case. A bug related to file matching with forced lower case was fixed in 4.0.1134.0. Perhaps it is related.

Please try it again with the latest version:

When I check the virtual machine every few days, I often find it is crashed and a window pops up says "SmartFTP Client has stopped working. Windows can check online for a solution to the problem and try to restart the program.". I did not get this before updating to the most recent version. What log files or data can I provide to help analyze this crash?

The duplicate transfers are gone though


It still crashes. I have isolated it to some extent. The crash only occurs when connecting to a local Windows IIS FTP server. It seems random. Over long enough period, sometimes seconds, sometimes hours, it will eventually crash when uploading to the Windows IIS FTP server. The crash has never occurred when transferring to other FTP servers that are not local and of unknown software.

If you can reproduce it in a relativ short time (minutes) please create a crash dump as described in this article: ... f2594.html

I was able to reproduce a crash twice within a few minutes of starting SmartFTP and emailed the 10K & 16K C:\Dump directory to If that email can't receive attachments, let me know and I will find a place to upload the file.

After more testing, I am able to reproduce a crash on demand with the following steps using SmartFTP build 1148:
1. Start SmartFTP, ensure the queue and schedule is clear.
2. Add new item to queue to copy a folder with delete from NAS to any FTP server
3. Right click and hit schedule
4. Add Monitor Folder - instant crash


Thanks. Can you post your system information from the menu: Help->About "System Information"?

I couldn't reproduce it right away. What folder are you monitoring? UNC or "local" folder?

Uhhhg. I can get SmartFTP to crash within 5 seconds... when NOT running the debug software. When running debug, it won't crash. (If a computer crashes and no debug is there to record it, did it actually crash?). Perhaps it is a timing issue, because SmartFTP runs much much slower with the debug software logging. Also, it seems more likely to crash in the non-administrator account. Here is the info from the non-admin account where I can reproduce the crash (when not running debug. No really, it crashes!):
+- System -----------------------------
Microsoft Windows 2008 Server Standard Edition (full installation)
Service Pack 2 (Build 6002)

CPU Speed : 2535 MHz
Total Memory : 8190 MB
Free Memory : 7270 MB

+- SmartFTP ---------------------------
Version : 4.0.1148.0
Time Stamp : 2010-12-07 22:26:38
Platform : x64
Id : 400128942
Maintenance : 2011-08-12
Days in use : 119

+- Language ---------------------------

+- Internet Explorer ------------------
Version : 8.0.6001.18943

+- Winsock ----------------------------
Winsock : 2.2

And how exactly do you make it crash? Is adding a new monitored folder enough?
We can only fix it with a crash dump or if we can actually reproduce it here.

To reproduce the crash, I just start a transfer from a UNC NAS to a local FTP server. It is comparing with delete about 5,000 files. If it finishes, it takes about 20 seconds. Normally it crashes in the first 5 seconds (if the debug software isn't running). I'll keep trying to get a good capture. Here is the Microsoft information:
Problem signature:
Problem Event Name: APPCRASH
Application Name: SmartFTP.exe
Application Version: 4.0.1148.0
Application Timestamp: 4cfeb65d
Fault Module Name: sfTransferQueue.dll
Fault Module Version: 4.0.1148.0
Fault Module Timestamp: 4cfeb3ad
Exception Code: c0000005
Exception Offset: 0000000000085088
OS Version: 6.0.6002.
Locale ID: 1033
Additional Information 1: 5d25
Additional Information 2: f0fe656e9b5f1aa149a043971a2c5950
Additional Information 3: ac05
Additional Information 4: e127402975c457dd023d2e0ee38de0ac

Read our privacy statement: ... cid=0x0409

We need more information:
Does it matter if it is a transfer from a UNC path or not?
Does it matter if you set the Synchronization to One-Way with Delete or just to One-Way?
How many files do we need to make it crash? Does it happen with just one file? e.g. try a transfer of one file a couple of times.
Does the number of workers have any influence? E.g. try it with 1 worker.

Does it matter if it is a transfer from a UNC path or not?
This is actually harder to test than it would seem. I'll get to this tomorrow.

Does it matter if you set the Synchronization to One-Way with Delete or just to One-Way?
It doesn't matter. It doesn't even matter if a file actually transfers. It is crashing even when the directories are identical and it is just running through a directory comparison.

How many files do we need to make it crash? Does it happen with just one file? e.g. try a transfer of one file a couple of times.
I can't get it to crash with just one file. It will not complete the full ~5,000 files when using the local FTP server. It will usually complete the full ~5,000 files when using one of our CDN FTP servers.

Does the number of workers have any influence? E.g. try it with 1 worker.
With 1 worker it takes about 50x longer to crash then with 10 or 20 workers. With 10 or 20 workers it will crash in the first 5 seconds. With 1 worker, it took about 45 minutes to crash.

No crashes:
There are no scenarios I can get SmartFTP to crash using the 32-bit build 1145 on a Windows XP laptop.
There are no scenarios I can get SmartFTP to crash using the 64-bit build 1145/1148/1149 when using the debugger on Windows 2008 server x64. I've been trying this for hours now.

Crash using x64 on Windows 2008 server x64 on a VMWare virtual machine:
It crashes in the first 5 seconds when using a local FTP server and 10 or 20 workers. It takes about 30 to 60 minutes to crash with 1 worker thread. I will crash after a much longer period connected to any of the three CDN FTP servers with 10 or 20 workers.
It is random when it crashes, I can't seem to find any specific trigger.
Bandwidth limits to not have an impact on when it will crash.

Next Steps:
I'm going to let it run over night with the debug on. Its very very slow, so maybe it will crash eventually. I'll test file uploads from the local drive tomorrow as well. I'm sorry I'm not able to get very good debug information. I appreciate you working on this using the limited information I am able to provide.

I tried to install the 32-bit version on the Windows 2008 server, but only the 64-bit version will install, so I can't test the 32-bit version on the server. The problem seems specific to this one combination of configurations.

Thank you for collecting all this information. It looks like a typical thread concurrency issue (missing critical section) which happens more often with a higher number of concurrent threads (e.g. more transfer queue workers) and "faster code execution" (no debugger attached).

Microsoft provides another tool than the recommended advplus to collect crash dumps: ... laylang=en
It might be worth a try to see whether it is less "intrusive" than advplus which as a result would trigger the crash faster. But I have a feeling it might actually do the same as advplus under the hood.

I will review the changes in the transfer queue that has been made between build 1045 and 1047 and see if I can spot the bug. But the best way is always a crash dump :-)

Build 1152 solved the problem. Thanks!

To correct the above post, 1151 fixed the problem, and that is what I installed. I noticed the monitor folder wasn't working, so I upgraded to build 1155. Build 1155 just crashed. I'll test a little more.

The crash must have been a fluke or our virtual machine. SmartFTP has been trouble free and stable for 7 days running 7/24. Awesome!


To get the dump of a sporadic crash we recommend this method: ... f2645.html

The benefit is that Tthe debugger will only be started after the application has crashed and won't use any resources while the application is running.