Copy to a Share folder (temporarily) hangs at the end

Hi,

I'm running DOpus 9.5.5 and I have two PCs on my home network. My main laptop is running Win7 Ultimate x64 and my secondary is running Win7 Home x64.

I have folders shared on my secondary laptop so that I can access those folders from my main laptop. When I do a copy of a single file, for example, to my secondary laptop's share folder, the progress bar will show 100% and it will just hang there for about 30 seconds. This isn't even copying a large file.

This morning I copied an 11K and after the progress bar reached 100%, it stayed there for another 30 seconds before it finally disappeared! Don't even ask what happens if I'm doing multiple files or folders!!

Anyway, when I do the exact same thing in Windows Explorer, it is instantaneous/no hangs after the copy is complete. Furthermore, I find that when I initially expand the "Network" node in Windows Explorer to see my other PC and its shares, that the performance is much faster than DOpus.

Originally I really thought it was a Win7/Network problem but since Windows Explorer always performs the same task without any performance issues, it's gotta be something with DOpus.

Sadly, when I have files to copy to my secondary laptop, I use Windows Explorer.

Any ideas as to why this is happening?

Thx!

Have you tried turning off your anti-virus and/or firewall (unless it's just the built-in Windows firewall) to see if that is triggering the slowdown?

Is Explorer definitely not taking the same amount of time as Opus, if you copy different files? (Ensure you copy different things, which haven't been created/accessed recently, in both programs otherwise caching may confuse the issue. Also, time the operation rather than looking at the progress bar; sometimes the overall operation takes the same time even if the progress bar moves/completes at different speeds in each program, again usually due to caching.)

For it hanging at the end of the file, though, my bet would be a virus scanner checking the file after it was written (perhaps only in Opus because Opus writes the file in a slightly different way, or reads different information when new files appear).

I turned of Webroot and that didn't make a difference.

Yes, Explorer is definitely and always faster. To your point, I haven't been just testing one file or file type. Like I stated earlier, it is so definitive that I use Explorer to do the copies; I don't even bother lauching DOpus anymore for that type of copy. I hate Explorer, but I have not choice because I can't stand the wait with DOpus.

I didn't mention it in my first message but at one point during the time when I was testing the copies with DOpus, I decided NOT to wait for the progress bar window to disappear. When it reached 100%, I went to the other PC and double-clicked on the file to see if I could open it up and it didn't work. The file could not be opened, as the copy had not yet completed.

Hi.
I realise this is a Zombie-Thread, but I am having what appears to be the same problem.

I am copying files from one server to another via my Win7x64 machine.
If I copy just about anything using Dopus from one to another, after the copy has completed, Dopus goes "Off with the fairies" for tens of minutes! Any Dopus windows that are open just white out. There is no network traffic, and turning off my AV, while being a dumb thing in itself, does not make any difference.
All folder/file/anything calculations are turned off.

This has been going on for months, and I've had enough. I 'upgraded' to 11.x in the hope it might solve this issue, but if anything, it seems worse.
Seriously, this is driving me Bats**t-crazy! (and I'm not the type of person who usually gets carried away like this)
The only way to restore Dopus to any kind of usefulness is to kill the dopus process.
Explorer works just fine, but it is so limited.
I copied two ~120MB MKVs from one server to another and the process finished over twenty minutes ago, and Dopus is still dead...!

Where do I start looking in order to solve this?
There must be some log somewhere...?
Thanks.
Susi

That would drive me crazy as well. :slight_smile:

What kind of network share is at the other end? (e.g. A Windows machine, a NAS box, or something else?)

Is it only certain types and/or sizes of files that are affected?

Is there still network traffic shown in Task Manager's networking tab while the delay happens?

During the delay, if Opus windows which interact with the share are blocking, does the same also occur with Windows Explorer if you point it at the share at that time?

Ah. No editing facility on the forum - nice.
Looked in %TEMP% for the dopus.minidumps folder and nothing there...
Totally at a loss now. :frowning:

Ooops. Sorry Leo, our posts crossed.
The servers are Synology NAS devices. Both are accessed via SMB shares.
Pretty much any file/collections of files over 100MB.
No, there is no ongoing "obvious" data transfer going on after the copybox completes, although I have noticed a couple of times that Windows Explorer will not open a remotely pasted file immediately.
All Dopus windows will hang. Sometimes I can open another by double-clicking on a different monitor's desktop, then after a few seconds that grinds to a halt and goes blank too.
I can browse the the same shares and copy files with Windows Explorer while Dopus is dead to the world.
I thought it might originally have been due to an incompatibility with Jumbo Frames on my network, but I reverted everything in order to check, and still was getting the same issues.
As I have a lot of drives/shares they are mapped in Windows as "Network Places" and not as drive letters. Would this be a problem do you think?
Thanks for helping.
Susi

PS,
I only have to kill dopus.exe, and not the helper

And...
...there's my fix... don't use "Network Places," use Mapped Drives.
Oh dear. I am going to run out of letters really fast... :frowning:

Why would there be such a difference between the way Windows Explorer and Dopus handles "Network Places?"

Thanks,
Susi xx

Synology NAS boxes have been known to cause lots of problems in the past.

Adding to what Jon said, updating the drive's firmware and software (sometimes there are two separate things) has often improved things in the past.

Unfortunately, it seems like new problems often appear in new devices (and it seems like they do most of their testing with Explorer, so that things which do things slightly differently run into weird problems), but they do seem pretty good at fixing things in updates if the problems are reported to them.

Adding to what Jon said, updating the drive's firmware and software (sometimes there are two separate things) has often improved things in the past.

Unfortunately, it seems like new problems often appear in new devices (and it seems like they do most of their testing with Explorer, so that things which do things slightly differently run into weird problems), but they do seem pretty good at fixing things in updates if the problems are reported to them.[/quote]
Thanks for the replies guys, and as a long-time user of Synology hardware I get what you are saying, but with all due respect, I think something else is going on here -

  1. If a directory on a server is mapped to a drive letter within Windows, copying/moving/etc., completes quite nicely without Dopus hanging.
  2. If a directory on a server is mapped as a "Network Location" within Windows (no assigned drive letter), then the issue with Dopus hanging up is very pronounced. Maddeningly so.

The method that Dopus uses when copying/moving files seem to be handled quite differently in each case.

Opus would not copy differently in those situations unless the drive is misreporting its type when mapped to a letter.

Setting Preferences / Miscellaneous / Advanced: copy_nonbufferio_threshold to 0 (zero) should remove the only possible difference in how Opus might copy the data between using a drive letter and a UNC network path.

(But if the drive letter is reported as a network drive, the setting should make no difference at all, because non-buffered I/O is never used with network paths. Some devices do mis-report, though.)

[quote="leo"]Opus would not copy differently in those situations unless the drive is misreporting its type when mapped to a letter.

Setting Preferences / Miscellaneous / Advanced: copy_nonbufferio_threshold to 0 (zero) should remove the only possible difference in how Opus might copy the data between using a drive letter and a UNC network path.

(But if the drive letter is reported as a network drive, the setting should make no difference at all, because non-buffered I/O is never used with network paths. Some devices do mis-report, though.)[/quote]
Hello Leo.
It seems your parting shot "Some devices do mis-report, though." Might be true.
I tried to set up four huge copy actions, between three different servers (Synology DS2411+, DS1513+, and an ancient Netgear ReadyNAS Duo) and my windows 7x64 machine (64bit Dopus installed), and it all just froze after the first copy started between the two Synology devices.
I killed the Dopus.exe process, restarted Dopus, and set the value mentioned above to "0"...
...and it seems to be working ok. In fact, it seems thus far to be great!

If you don't mind, I'll keep an eye on this over a few reboots of the Win7 PC and the servers for the next few days and see how things go?
But for now - please accept a huge THANK YOU as I can finally use Dopus again for network operations!

Susi xx

Weird, but good that it worked!

If you go to the Computer folder and enable the Type column, what does it show for the mapped drives?