Delay when renaming in network drive (Win 7)

[abr]

An user reports some delay of about 5 seconds on their Windows 7 machines, when renaming items on a network drive after having pressed the Enter key.
Also, the display of items in the listers will take that long. He has turned off the option »automatic calculation of folder size« for the network drives as well
as the "content type recognition" option. As he reports, this delay does not occur when using the Windows Explorer. Are there more settings, that could be
tweaked in order to speed up the process?

[Leo]

A long delay like that makes me guess the network folder is hosted by something Linux-based, running a version of Samba that's configured to only check for changes every 5 minutes.

Changes to folders are not being detected

Opus should detect changes to folders automatically, but there are some things to check first: Fully exit Opus and restart it, in case the problem is with the Windows change-notification system losing track of the request from Opus to listen to ch…

[abr]

Well, i think he would have mentioned that. But i will call back, if they use other components beside Win 7.

[abr]

Indeed, the user is using FreeNAS (based on FreeBSD) which utilizes samba. Is there a way to speed
things up a bit? You gave a hint concerning sambas configuration. Would it help to lower the time &
if so, which value would you recommend?

[Leo]

It depends a great deal on the type of Samba build and the OS/filesystem drivers.

Best to ask whoever supports FreeNAS or someone who is an expert on Samba.

[abr]

Leo, thanks, i forwarded it to the user, although he might wonder, why that delay
does not occur with Explorer. Most likely it´s because Opus uses different routines
of Samba handling, which may not be tweakable.

[dsb]

@abr

Leo, thanks, i forwarded it to the user, although he might wonder, why that delay does not occur with Explorer. Most likely it´s because Opus uses different routines of Samba handling, which may not be tweakable.

You might want to ask him if he has the same delay issues when DOpus displays the file listing as UNC paths instead of drive letters.

I have a feeling this is related to the problem I’m running into here:

Non–Windows network folder listings not auto–updating

Folders mapped to drive letters on my non–Windows server aren’t automatically refreshing in Directory Opus. The target server is a Nexenta Core box (see http://www.nexenta.org — it’s basically OpenSolaris) running cifs on the zfs filesystem. Any ch…

FreeNAS and Nexenta Core have a lot in common, especially if he’s using zfs on FreeNAS (Nexenta is based on OpenSolaris).

[Roogla]

Hi.. (the original request seems to be mine 8)

we tried to track down this problem with wireshark to see where the delay is located..

there are 1-3 seconds the samba server needs to respond to a "query full fs size info" (SMB-Code: 0x03ef)..

since this is called about 3 times while scanning a network directory the total delay till the folder content is displayes is 5 seconds and up..

the windows (7) explorer seems to not call out for full disksize while displaying network folder content..

btw.. the delay is present when the network drive is connected to some drive-letter and while accessed directly by \smbserver\sharename ..

we already tried to tweak the samba server by giving hints of "max disk size" and "block size" but nothing changed here..

since the (evil) windows explorer does not call those procedures why does diropus? 8)

hope this helps to track down this bug and to implement a config-switch to turn this behaviour off and on again...
(isn't that always the solution to turn things off and on again?..hrhr)

regards..
solution searching guy 8)

[Leo]

Thanks for the info & investigation (and sorry the post wasn't moderated sooner; seemed like phpbb didn't notify me of it).

So the Samba server is fast to respond to everything except the "query full fs size info" command? Any idea why that might be happening? Is it an unusual OS, filesystem or Samba build at the server end? Maybe something in that environment that makes calculating the disk size slow? (e.g. Complex quota system or something like that?)