Custom Query (292 matches)

Hosting shares on eCS from Windows works fine. Moved share to Windows 7 and mapped from eCS 2.0 using various Samba Client builds. Tried using EVFS and Netdrive to mount.

Crash only happens when running multiple DOS applications from a DOS window via the share on Windows 7. Executing the same file (BBS nodes) via DOS window. It works for awhile but then get a random crash (JFS trap 000e). I use JFS for my boot drive for eCS 2.0.

Using SAMBA users and groups, I cannot add a user. The dialog is filled out, but when I click OK, the error is

Line 68 of PB_AddUserOK_Click in smbusers.VRM

password.nx - Crypt(VRGet('EF_passowrd', 'Value'), salt);

I look for a program named Crypt, but nothing is found.

This continues the discussion we've had on the dev list, as it just happened to me with a NTLM/SMB1 share.

Connection was mapped and working. It sat idle for 61 minutes and few seconds. using 4OS2, I attempted a tab completion for a path, and got a beep (as it might if the drive were disconnected or the beginning of the path otherwise invalid).

Using ndpsmb-samba_4.2.3-heimdal-20150716b, log.ndpsmb shows:

2015/07/28 14:16:39.58: 9 2: NdpRsrcQueryInfo in
2015/07/28 14:16:39.62: 9 2: NdpRsrcQueryInfo 0
2015/07/28 14:16:39.62: 9 2: NdpRsrcQueryInfo in
2015/07/28 14:16:39.62: 9 2: NdpRsrcQueryInfo 0
2015/07/28 14:16:39.62: 9 2: NdpQueryPathInfo in [0x6213c0] <im*>
2015/07/28 14:16:39.63: 9 2: NdpFindStart in [0x6213c0]
2015/07/28 14:16:39.63: 9 2: NdpFindStart: dir [\], dir_mask [im*], mask [\*], szPath [im*]
2015/07/28 14:16:39.63: 4 2:  smbwrp_filelist
2015/07/28 14:16:39.63: 1 2: Filelist <\*> on master <WORKGROUP> wgrp <workgroup> server <othello> share <data> clidev <A:>
2015/07/28 14:16:39.63: 1 2: list_files
2015/07/28 14:16:39.63: 9 2: dircache_list_files []
2015/07/28 14:16:39.63: 9 2: findDirCache: []
2015/07/28 14:16:39.63: 9 2: findDirCache: entry [LOTUS\Cantiag\ARCHIVE.FWK\COMMERCE.WK1]
2015/07/28 14:16:39.63: 9 2: findDirCache: entry [LOTUS\Cantiag\ARCHIVE.FWK]
2015/07/28 14:16:39.63: 9 2: findDirCache: entry [LOTUS\Cantiag]
2015/07/28 14:16:39.63: 9 2: findDirCache: entry [LOTUS]
2015/07/28 14:16:39.64: 9 2: findDirCache: entry []
2015/07/28 14:16:39.64: 9 2: dcePathEqualTo: [] []
2015/07/28 14:16:39.64: 9 2: findDirCache: 0x66f9e0
2015/07/28 14:16:39.64: 9 2: CacheRead: entry 0x66f9e0 found for []
2015/07/28 14:16:39.64: 9 2: CacheRead: expired
2015/07/28 14:16:39.64: 9 2: CacheRead: [], 0
2015/07/28 14:16:39.64: 4 2: list_files level 260. mask <\*>
2015/07/28 14:16:39.67: 9 2: NdpFindStart <im*> (\im*) cnt 0 0
2015/07/28 14:16:40.62: 9 2: NdpRsrcQueryInfo in
2015/07/28 14:16:40.62: 9 2: NdpRsrcQueryInfo 0
2015/07/28 14:16:40.62: 9 2: NdpRsrcQueryInfo in
2015/07/28 14:16:40.62: 9 2: NdpRsrcQueryInfo 0

A subsequent:

dir g:\

paused for a few seconds, then provided results. Afterward, the same tab completion as above worked as expected (no delay; no beep).

Obviously, using CMD this would not be an issue, as there is no tab completion. I suspect that if we were able to cache the dir entries, this might also not be an issue, as we would return results from cache first (though an hour would be a long cache timeout).

Note that EA support is enabled for this share, even though the server does not support EAs over CIFS. I doubt that this has any bearing, however (the log does correctly report failure to get EA data when listing files).