Custom Query (292 matches)

Hi/2.

Thanks for your work.

BTW, I tried to use SAMBA server 3.0.28. But it crashed. So I looked in to popupos2.log. The cause is LIBLDAP.DLL. I also tried to find other LIBLDAP.DLL. Bingo! I found another LIBLDAP.DLL in NETSCAPE v4.61.(\NETSCAPE\PROGRAM\). So I cannot use NETSCAPE and SAMBA concurrently.

Would you mind changing name of LIBLDAP.DLL to another one ?

KO Myung-Hun

As described in : ​http://bugs.ecomstation.nl/view.php?id=1008

Vitalli had a look at this and wrote:

Hi Bart,

the log shows that this is a problem in the smb client. It can not receive listings which require 3 or more smb packets. It is >200 files per directory.

Here is the excerpt from the log:

Client request 13 paramlen 1805 len 131072, reconnect 1. State 006ba1c0 Filelist <\blondeguy\cubic\tools\PVCS\*> on master <WORKGROUP> wgrp <> server <littlebopeep> share <jfs> clidev <A:> list_files level 2. mask <\cubic\tools\PVCS\echo..COM> list_files 103 0 80889 1 received 103 entries (eos=0) list_files 101 0 80889 0 Error: Looping in FIND_NEXT as name WORKSTN.INI has already been seen? received 101 entries (eos=1)

Note the 'list_files level 2' which indicates an old server. I've tested with a XP server (level 260) and the problem is not reproducible.

The bad code is in smbwrp.c: static int list_files(struct cli_state *cli, const char *Mask, uint16 attribute, void (*fn)(const char*, smbwrp_fileinfo *, const char *, void *), void *state)

The following happens: the client receives first part of the listing and then issues a find_next request. The second part of the listing is also received and in the log it is seen that EndOfListing? is false: 'list_files 101 0'. But then the client goes to the Error: Looping in FIND_NEXT as name %s has already been seen?\n" statement and ends the listing.

That is probably confuses the system and the hang occurs.

To fix the problem one have to reproduce it: just try to list a directory with a lot of files (>300) on a OS/2 share.

Then a bit more debugging is needed to find out why the client receives the duplicate filename and how to deal with it: skip or what.

I believe Paul or Yuri can fix the problem. Ask them.

Best regards, Vitali.

The GUI for EVFS as included in eCS 2.0 RC4 is unable to determine if the resource was actually connected properly or not. Below is a cut & paste from a discussion with Alex Taylor (author of the GUI) me (Joachim) and Vitali.

===

the return code of EvfsRxMount? indicates whether the resource

was initialized and parameters were accepted by the plugin. It does not indicate the resource availability. That is, it is possible to mount a resource that is not accessible at the time of the mount. That is the design.

If you have to verify, whether the resource is actually accessible, you have to do a file system operation on the resource and verify the result of it.

Return codes for all REXX functions are generic OS/2 return codes converted to a decimal string (like ERROR_INVALID_PARAMETER is '87', etc).

Okay, thanks for the info. So this would require some additional coding but seems not impossible...

I'm not sure... how could I tell the difference between an attached directory that simply contains no files, and an empty mountpoint (whose attach failed)?

It would seem there's also no way to return "login failed" to the user.

===

Hi Joachim, Alex,

it is possible to implement an IOCTL in the samba plugin. The IOCTL would return information about the samba resource. I believe it is the most suitable method, as it will allow to return any information: login failed, etc.

So after a mount, an additional IOCTL call to the plugin will be made by the script.

I think doing an IOCTL from rexx is not implemented in evfscall, so a separate executable (or REXX callable DLL, or additing the function to evfscalls) will be required.

I will send a C example of implementing an IOCTL later today.

Best regards, Vitali.

===

here is what to do.

In the plugin (ndpsmb.c) implement:

int APIENTRY NdpIOCTL (int type, HRESOURCE resource, char *path, int function,

void *in, ULONG insize, PULONG poutlen)

{

Resource *pRes = (Resource *)resource;

if (function == 100 ) /* Arbitrary value */ {

SAMBAINFO *pInfo = (SAMBAINFO *)in; fillResourceInfo (pRes, pInfo); poutlen = sizeof (SAMBAINFO); return NO_ERROR;

}

return ERROR_NOT_SUPPORTED;

}

In the application call:

SAMBAINFO info;

fullpath = path to just created resource.

ULONG cbOut = sizeof (info); rc = EvfsPluginIoctl? (100, "ndpsmb", "smbfs", fullpath, &info, sizeof (info), &cbOut);

That should eventually call the custom fillResourceInfo which can return whatever is required in the SAMBAINFO structure.

Let me know if there are any problems.

Best regards, Vitali.

===

We'd like to have the capability to perform a status check in REXX, but am unsure if the above is sufficient to implement this. It is also unclear to me who is supposed to implement what :)

Thanks in advance,

Joachim