Long freezes accessing Mac OS X 10.8.5 network share

[CCRDude]

I want to report a possible bug in combination with Mac OSX samba shares:

• I've got a Mac running 10.8.5, and have Samba-shared a standard folder of my home folder.
• On a Windows Machine (Win7 64 bit), I've mounted this share as drive P:.
• Windows Explorer browses this share fine.
• Total Commander 8.51a (both 32 and 64 bit) freezes when switching folders on that share.
• Freezes means that for one to five minutes, TC doesn't react, clicking it would cause Windows to show the process not reacting dialog.
• Using the SMB path instead of the mounted drive letter, it freezes the same.
• Disabling all icons from Configuration - Options - Icons (set to "No Icons"), it freezes the same.
• Accessing a Samba share on Mac OS X 10.6.8 works fine.

Now one could say that since 10.8.5 isn't the newest release, this bug is not relevant, but a bug causing a freeze on non-perfect SMB implementation is always a bug and might affect other constellations as well.

I'll test this on a 10.10 next week and add more details on that here.

[ghisler(Author)]

So far you seem to be the only one with this problem. It sounds like some kind of timeout. Maybe a function like the loading of the icons causes it? Try turning off the icons in TC Configuration - Options - Icons. If this helps, we can try to find out which association is causing the problem. If not, you have probably a network routing error.

[CCRDude]

Thanks for the reply

See my seventh topic (second from the bottom) - Icons are disabled.

See also my third topic - Windows Explorer wouldn't work fine when I had routing issues, right? Plus, I saved files on that share every few minutes for two days without freezing.

By the way... snce a folder is accessed in TC, accessing files in that folder works fine, e.g. using the viewer. Just changing folders causes the freeze, TC only, not Explorer.

I wonder if plugins could cause this? Will have to check my plugins on Monday.
So far I've reverted to using a Windows Share on the Mac instead of the other way round so that I can use TC on the Windows machine

[CCRDude]

I'm able to provide two more details:

1. This happens as well with all plugins disabled (plugins folder renamed)
2. This does not happen connecting to a Yosemite (OS X 10.10) share

So I went a bit further in testing...

3. I confirmed that this issue happens even when connecting to a fresh installation of OS X 10.8 on an empty hard disk.
4. I didn't believe the "your routing is at fault" argument for reasons above, but tested a totally different connection anyway, this time through a NAT instead of directly on the same subnet. Same issue.

[ghisler(Author)]

Total Commander only uses the normal Windows FindFirstFileEx/FindNextFile functions, nothing special. Unfortunately I have no idea what I need to change to make it work with OS X, sorry.

[CCRDude]

It's never that simple

Afaik you're using Delphi? DirectoryExists for example is badly implemented especially when it comes to network drives - there are situations where it reports that a Directory exists even when it doesn't, which can lead to follow-up issues trying to access it (DirectoryExists checks whether certain errors occur and assumes the directory exists otherwise, instead of checking for success). If that Delphi behaviour spreads to other RTL functions (or you're using DirectoryExists on something here), it could simply be that the Apple SMB/CIFS implementation returns a different error than standard Windows, which Windows still deals with as an error, and Delphi fails there.

So I'm glad to hear you're using Win32 API calls directly.

With that just being an example, I'll use API Monitor on Monday to check if I can find out what call is hanging so long (I'm not near a Windows machine right now).

[ghisler(Author)]

I'm not using the Delphi functions, I'm directly using the Windows API functions FindFirstFileW, FindNextFileW etc.

You can try using the tool "Process Monitor" (not Process Explorer!) from www.sysinternals.com (part of Microsoft) to find out which function is hanging.

[CCRDude]

I prefer API Monitor, since it allows me to hook the complete system, or just as much as I want, while Process Monitor only monitors a subset of relevant calls. I tried both anyway.

The only calls that take very long are calls to NtCancelIoFile in the thread you use for monitoring changes (the one also using NtNotifyChangeDirectoryFile). Your main thread probably waits for this somehow?

[ghisler(Author)]

You can try to turn off directory watching in menu Configuration - Options - Refresh (lower half). By default, this is turned off. Maybe it helps? It is using ReadDirectoryChangesW to get notifications when something changes on the drive.

[CCRDude]

Thanks, that's a good work-around

[ghisler(Author)]

Ah, nice to hear that it helps! Seems like the SMB implementation of this function on MacOS is garbage.

The question is: How can I detect that the remote system is MacOS, so I do NOT call ReadDirectoryChangesW for these systems? Does anyone have an idea?