OOo File open dialogue is very slow on a Samba share with lots of files.

[Herwig Bauernfeind]

Basically this is a followup to Ticket #120. While the reason for Ticket #120 was the missing cache of our Samba Client, the reason for this ticket is, that the ammount of time OOo File Open Dialog needs to read a directory rises exponentially (for n directory entries it has to do n * n reads).

It appears that this is a problem of the OOo Filedialog and not of Samba as my tests on a directory with 4700 entries revealed:

• OOo 3.2.0 needs ages (never let the operation complete, killed it after 20 minutes), as it blocks the machine.
• OOo 1.1.5 which used the Odin-Filedialog does the same within 1-3 seconds.
• StarOffice 5.1a (which has a similar Filedialog as OOo 3.x) needs approximately 12 minutes (and does not block the machine).

[Silvan Scherrer]

needs to be retested with latest AOO/2 4.x

[Lewis Rosenthal]

I can say (not confirm) that with:

7-04-15 17:23 5,512,638 124 ndpsmb.dll

browsing files from OOo 4.1.1.1 located on a NetWare CIFS share (on the LAN, not across a bandwidth-constrained link) seems to take longer than it should, with high CPU. opening the same folders from the WPS drive object uses less (normal) CPU, and the files are displayed with associated icons.

Browsing some other directories from the WPS icon which contain many large Windows files with included icons takes longer, but this is not unusual.

Browsing the same OOo document directories using the NetWare requester is very responsive with low CPU.

The PMView FOC is also considerably slower using Samba than locally or using the NetWare requester, though this could have more to do with thumbnail caching (tested against !Netware CIFS, via SMB1, which does not support EAs and also against Samba 4.1.8 on openSuSE 13.2, via SMB2, which does support EAs - similar results).

[Paul Smedley]

Logs would be useful....

[Paul Smedley]

A quick look at logs here shows that aoo seems to somehow trigger multiple connections to the samba server in very short succession.

In my case, aoo is set to open q:\documents\openoffice by default, in log.ndpsmb I see: many, many cases of 2016/07/09 17:14:45.65: 8 2: adding <documents> 289 35012608 261, each with an NdpCreateConnection. I also have a log from a logging ndctl to review. Will try take a look at piece together what's happening soon.

[Paul Smedley]

OK, I think this code in ndpsmb.c is the issue

		/* This plugin always reads a complete directory listing and filters results
		 * using actual mask (state.dir_mask) in getfindinfoL.
		 * May be this was a workaround for some server bug.
		 * If this will be changed, then directory listing cache must be changed too,
		 * and must remember the mask, which was used to obtain a listing.
		 * Now the directory cache saves complete directory listings and then uses them to find
		 * information about single files.
		 * However, with a directory cache, it is probably faster to get a full listing and
		 * then use it to obtain info about separate files than to perform a network
		 * list query operation using actual wild cards for each file. Some application,
		 * for example OpenOffice, do this.
		 */
//FIX ME
		p = getlastslash(state.mask);
		if (p)
		{
			*(p + 1) = '*';
			*(p + 2) = 0;
		} 
		else
		{
			strcpy(state.mask, "\\*");
		}
//End FIX ME
		debuglocal(9,"NdpFindStart: dir [%s], dir_mask [%s], mask [%s], szPath [%s]\n",
			state.dir, state.dir_mask, state.mask, state.fullpath);

Seems OOO does a query on an individual file, but due to the above, netdrive ends up doing a full directory listing for each file as mask is set to *.

I will do some experiments with setting state.mask to the same as dir_mask