Slow file access times - Client 2 SP2 for Windows 7

[jlarson1975]

Greetings,

We're currently investigating an issue after migrating to Windows 7 and Novell Client 2 SP2. The problem has been seen with an older app written in MicroFocus COBOL and occurs on a Windows 7 machine when attempting to access a file that has been added to a file share on a Novell server. There appears to be a 20 second delay between when the files are dropped into the folder and the app is able to recognize that it is actually there. The delay is very consistent, leading me to believe a timeout is in play. It also never improves after first access to the folder, consistently staying at 20 seconds for each file accessed. I suspected that a multiple provider issue was at work, but LoginCapture Credential Provider and NetWare Services are at the top of the provider order. Here are the additional steps I've taken when troubleshooting and attempting to resolve the issue -

Disable Offline File Synchronization
Disable Autotuning
Disable Windows Search Service
Disable NTFS Last Access
Turned off Windows write-cache buffer flushing
Changed Network Provider order to Microsoft first (this is opposite of expected, but just in case, I tried it)

In Novell Client, toggled the following settings to both On and Off in all cases
- UNC Path Filter
- File Caching
- File Commit

- I also tried various combinations of Name Services with no effect.

Finally, In the registry I tried the following changes -
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\NCFSD\NetworkProvider
DeviceName Changed from \Device\NCFSD to \Device\NetwareRedirector
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Mup
Add DisableDFS REG_DWORD and set to both 1 and 0 (currently 0)

Anyone have any additional suggestions?

[jmarton2]

jlarson1975 wrote:

> We're currently investigating an issue after migrating to Windows 7
> and Novell Client 2 SP2. The problem has been seen with an older app
> written in MicroFocus COBOL and occurs on a Windows 7 machine when
> attempting to access a file that has been added to a file share on a
> Novell server.

Which specific version of the Novell Client? If it's the original SP2
release, that's quite old. The current release is Novell Client 2 SP2
IR5.

http://download.novell.com/Download?buildid=vpUu7cYba-A~

Also, when you say "a Novell server" are you talking about NetWare or
OES Linux? Which specific version of NetWare or OES Linux (including
patch level)?

--
We're your Novell--again. http://www.novell.com/promo/backtobasics.html
BrainShare 2013 is coming! http://www.brainshare.com

[jlarson1975]

Thanks for the response. We were using IR4, so I've now installed IR5 on our test machine and tried it out with the same results. As far as the server, it is a Netware server although I don't have the version or patch level information yet. I'll post that as soon as I have it.

[ataubman]

Is it just this one app that is slow? What about, say, notepad or office, is there a similar delay? Windows explorer?

What about on an XP workstation with client32 4.91 sp5? Same issue?

[jlarson1975]

I'm still waiting on the version/patch info for our Netware server, however in the meantime to answer your questions, Andrew - on XP (with 4.91 SP4) there are no issues.

For Win7 - In windows explorer, it requires a manual refresh typically to update the list, but other apps seem to open without the delay. Along those lines though, the app in question uses file size to determine if a file is "ready" to be opened or still in the copy process. In running wireshark traces, it looked like the file size attribute may not be updating immediately and seemed to not be available for "Obtain File or Subdirectory Information" requests until the 20 second mark (if I'm reading them right). At the same time, if I triggered the copy process and manually opened the file outside of our app, it is then available in the app before the 20 second mark. It's almost like manually opening the file forced the size attribute to be available. I'm an application guy so reading traces isn't my forte, but that's what it looked like.

[jlarson1975]

Update - the Netware server is on 6.5 sp8.

[ataubman]

Alright, well this looks like one that needs an SR logged, and submit that lan trace for analysis - I doubt we'll be able to help here.

[jlarson1975]

We'll probably end up logging an SR, however some additional info after troubleshooting today. The process in question is a file restore. Basically the process checks for the existence of a file, and if it isn't there, it issues a restore process that typically takes two or three seconds, then rechecks the same folder to see if the file is available. To do this check, we're executing the Win32 api GetFileAttributesEx. What's interesting is while watching a trace, after the initial check of the file existence, subsequent requests for the next 20 seconds resulted in no traffic to the netware server at all. That definitely has the appearance of a cache being in play.

[jlarson1975]

Just an update that we've been able to work around the issue in code. On the initial file existence check rather than executing GetFileAttributesEx, we are first doing a straight open on the file. If the file doesn't exist and the open fails, this apparently behaves differently and the fact that the file doesn't exist is not cached for 20 seconds. It's very odd behavior, but at least we could work around it.