Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - herwigb

Pages: [1] 2 3 ... 8
Multimedia / Re: SNAP - Quiet mode?
« on: 2012.07.17, 06:21:17 »
AFAIK it depends on the key type whether the splash screen is displayed or not.

OEM key = Serenity = eCS Version = Splash Screen.

Personal key = you, me = no splash screen.

General Discussion / Re: Injoy
« on: 2012.06.25, 16:49:42 »
The way I read it, bitwiseworks is owned/run by Dmitry, Silvan and Herwig
Yes, exactly, bitwiseworks is owned and run by the 3 of us.

As for new features, as I explained, Windows 7/8+ 64 bit support has top priority for "our" first release, however there is also work going on on a major performance issue fix on eCS.

I can't say much more now, it's a rough path to get everything going and if there is one thing we absolutely want to avoid: Disappointing eCS (OS/2) users - that happened just too often in the past.

General Discussion / Re: Injoy
« on: 2012.06.22, 18:53:00 »
As the 3 of us are more or less heavily engaged into eCS and OS/2, I can savely assure that there are absolutely NO plans to cancel the eCS (OS/2) version of InJoy Firewall.

While we have to close a technology gap on Windows (7/8 support and 64-bit support, and we have to concentrate to close that gap), there is no such gap for eCS (OS/2) - so when it comes to new features and fixes the eCS (OS/2) version will be on par with Windows, remember InJoy is really multiplatform - that's one of its strengths!

The eCS (OS/2) version will definitely not be in an ugly duckling position for a foreseeable future.

And this is not a private opinion of mine!!!

General Discussion / Re: Injoy
« on: 2012.06.20, 11:44:21 »
Hopefully lots of people have seen it  ;D

Well, not quite. I now get an error popup when I turn it off, and click Apply. I will update the incident.
So sorry. Little last minute change that was not supposed to break anything......  :-[

It is fixed in [url][url] (no other changes since yesterday).

I see no change. It still tries to use the 168.254... address.
This is no surprise. Samba will try to use any interface with an associated IP. It is not the the job of Samba to test whether an interface works or not.
My workaround just ensures that in case there is also another valid IP address the local link address is not enforced by putting it into LMHosts...
One should reset LMHosts however to make sure any old invalid entry is gone...

I also discovered that there is an EVFSGUI.INI file, which is hidden in x:\OS2.
Well, it was already that way, when I took over development. For compatibility reasons I did not change this, although I am doing it differently in the other Samba GUI tools...

After editing that with an INI editor, to turn off the "Store credentials until next reboot" setting, it seems to be working better. Win7 seems happy too.
This is highly improbable, because having stored the user/password in memory has only the advantage of not having to retype it every time.  Everything else is just exactly the same. You need to be more specific, if I should take a closer look, although I don't have the faintest idea...


The daily update  ;)

I tried using the "Store credentials until next boot" setting

EVFSGUI really should be able to handle having the same name for windows and eCS.
That works, just tried. Wild guess: Credentials are not really the same (username+passwort+privilegues).

I have two interfaces
This is a known problem (and a design flaw in EVFSGUI). I built in a workaround (as this will be tricky to really fix properly): A machine that appears to have a local link (169.254..) IP (this is always wrong) is never added to LMHosts... Not really smart, but better than before.

In addition a "Clear" button was added on the dialog page to remove credentials from memory. The network neighbourhood now displays the user context that is used during browsing - that should help finding out why a specific machine cannot be browsed (or is not shown).


what you see on the commandline is part of the debug log.

smbtree -S -N -d=0

I guess this will be empty, too.

You should see something like the attached image...

Could you eventually send me the complete output of the VX console window? I might have spotted something, but need to take a closer look.

AN UPDATE: It seems like my problem is totally unrelated to Samba and rather dependent on the network settings in the other machine (a w2k machine). Thanks Herwig for the help with this.

Networking / Re: Samba and utime()
« on: 2012.06.06, 14:48:12 »



try this one
I fixed 2 bugs, one in the RPC library (saw that in your log, line 438 etc.) and the second is the sharetype error - this one should be really gone now.

It seems that smbtree.exe might need some work. Sometimes, it works okay, but if anything changes (like turning off one of the machines), it seems to go off into it's own little world for a while.
I am not convinced of that (several reasons requiring very lengthy explanations) - I would only do that if a Linux smbtree would perform differently than an eCS smbtree.exe in a given situation. The way the SMB browsing stuff works makes it easy to see breaks like this, especially in case with no permanently present WINS server.

BTW I'd setup os level on your server to 70 or the like. With 40 Samba will loose browser elections against any WinXP machine AFAIR...

Networking / Re: Samba and utime()
« on: 2012.06.06, 07:30:14 »

you might see a flavor of this issue


The -N switch is used in many Samba commandline utilities (most notably smbtree.exe and smbclient.exe) to make the command run with guest privilegues only.

smbtree.exe, smbclient.exe and nmblookup.exe are used to gather all the information required in the network neighbourhood.

In case there is a user/pw on the "new connection"-dialog page entered, the commands are run using these, otherwise the commands are run using the -N switch. If you want to make sure the commands are run using -N switch remove user/pw from the "new connection"-dialog page. I know, it's a bit odd this way....


I note that I  now have a lmhosts file in my mptn\etc\samba directory. It lists in fact active computers and their ip numbers, but doesn't seem to make use of that knowledge as the "neighbourhood" is not populated.

The network neighbourhood creates and populates the lmhosts file, which is used by the plugin. The network neighbourhood is not populated by the lmhosts file.

The network neighbourhood is basically a GUI wrapper for the smbtree.exe command. if smbtree.exe does not produce reasonable output, the network neighbourhood will stay empty, too.


try this one
The only way I found to trigger your error was to remove the language file, in that case the mount type was not properly initialized, which lead to the behaviour you see.
This EVFSGUI now complains if it does not find a language file and the mount type is initialized with the built in string list from the guy (square brackets around the text in this case).

This is a debug version, please enable debug also in the global settings and paste the complete content of the VX console window to a file and attach that to the ticket.

Yes, the crash is fixed. Now, I get a popup saying that whatever type of share I am trying to mount, is an "unknown mount type". I reply to that popup, and it proceeds to, happily, mount what I requested. There is no evfsgui.err file now. If I try the mount from the New resource tab, I don't get the popup.
Ok, I see what happens, not sure why, but I will fix that, can't be too hard.

It seem that NMBD.EXE is starting before the DHCP stuff gets set up
Ok, I never tried that, however I this likely to fail. Eventually code could be added to smb.cmd to wait until DHCP has completed - however, don't expect to see that soon.

All you describe here is normal Samba behaviour. The DMB should always be present, in case it vanishes, it might take several minutes for another machine to take over, meanwhile requests will go to limbo - expect loooooong delays in such a situation. There are ways to make sure only a certein machine becomes DMB, this is a matter of RTFM ;-) (look for "os level" setting).

However while I thought over that all, it came to my mind that there's chance to see 2 DMB in the network neighbourhood with current EVFSGUI 2.5 - which is wrong, there is always only one DMB for one domain at a given time - if that changes while EVFSGUI still builds the network neighbourhood, and EVFSGUI already processed the earlier one and later on the new one 2 DMBs will be displayed - I need to think over how to fix that (which wont be trivial).

Just as a side note: Network neighbourhood (called ressource browser) in IBM Peer always was flaky and could easily block the WPS forever....

Sorry, I overlooked the second .err file, only the first one was fixed in the 20120529 .exe.

The second (and third) one is strange and should not happen at all - try this one
The error is not fixed, however it should not crash, but display an error message box, which should give us a hint, what's exactly happening. It might crash after the message box....

Anyway, I need to know what the message box says, and, in case it crashes afterwards, the new .err file.

Pages: [1] 2 3 ... 8