• GoldEd+ v1.1.5 - not working on Mac

    From Fermin Sanchez@2:301/123 to All on Sun May 9 18:07:00 2021

    Hello everybody!

    I have resurrected my Fidonet node, so far, so good. And while everything seems to be running fine on a Windows based server, including GoldEd+, I wanted to run the editor natively on my Mac. I'm running the latest "Big Sur" version.

    Now for the tricky part - not sure if that's actually possible. I have, for example, an areas.bbs that gets automatically generated by FMail. It looks like this:
    ******
    2:301/123 ! Fermin Sanchez
    ; Created by FConfig-W32-2.0.1.2 - Sun May 09 18:05:12 2021 !C:\BBS\msgbase\allfix_file ALLFIX_FILE 2:301/1 !C:\BBS\msgbase\cooking COOKING 2:301/1 !C:\BBS\msgbase\earth EARTH 2:301/1 !C:\BBS\msgbase\ebbauser.ger EBBAUSER.GER 2:301/1
    ... (etc...)
    ******

    My functioning GoldEd.cfg on my Windows server has various entries that use the typical Windows paths, for example:
    ******
    #Area definitions
    AREADEF Netmail "NETMAIL" 0 Net OPUS C:\BBS\netmail
    AREAFILE AreasBBS c:\bbs\msgbase\areas.bbs
    ******

    I therefore tried using "MAPPATH" on my Macs golded.cfg to rewrite whatever c:\.... to /Volumes/bbs/....:
    *******
    #Info about me
    USERNAME Fermin Sanchez
    ADDRESS 2:301/123
    AKA 2:301/123@fidonet.org
    NICKNAME Fermin

    #Special for Mac
    MAPPPATH c:\bbs\ /Volumes/bbs/
    MAPPPATH c:\bbs\config\ /Volumes/bbs/config/
    MAPPPATH c:\bbs\GoldEd\ /Volumes/bbs/GoldEd/
    MAPPPATH c:\bbs\msgbase\ /Volumes/bbs/msgbase/
    MAPPPATH c:\bbs\netmail\ /Volumes/bbs/netmail/
    MAPPPATH c:\bbs\nodelist\ /Volumes/bbs/nodelist/
    ********

    Nope, doesn't seem to work. GoldEd creates the JAM database files including their paths on my Mac:
    ********
    fermin@MBPHome bin % ls -lsa
    total 7240
    0 drwxr-xr-x@ 68 fermin staff 2176 May 9 18:31 .
    0 drwxr-xr-x 5 fermin staff 160 May 9 18:09 ..
    16 -rw-r--r--@ 1 fermin staff 6148 May 9 18:30 .DS_Store
    0 -rw-r--r-- 1 fermin staff 0 May 9 18:30 C:\BBS\msgbase\allfix_file.jdx
    8 -rw-r--r-- 1 fermin staff 1024 May 9 18:30 C:\BBS\msgbase\allfix_file.jhr
    0 -rw-r--r-- 1 fermin staff 0 May 9 18:30 C:\BBS\msgbase\allfix_file.jlr
    0 -rw-r--r-- 1 fermin staff 0 May 9 18:30 C:\BBS\msgbase\cooking.jdx
    8 -rw-r--r-- 1 fermin staff 1024 May 9 18:30 C:\BBS\msgbase\cooking.jhr
    0 -rw-r--r-- 1 fermin staff 0 May 9 18:30 C:\BBS\msgbase\cooking.jlr
    0 -rw-r--r-- 1 fermin staff 0 May 9 18:30 C:\BBS\msgbase\earth.jdx
    8 -rw-r--r-- 1 fermin staff 1024 May 9 18:30 C:\BBS\msgbase\earth.jhr
    0 -rw-r--r-- 1 fermin staff 0 May 9 18:30 C:\BBS\msgbase\earth.jlr
    0 -rw-r--r-- 1 fermin staff 0 May 9 18:30 C:\BBS\msgbase\ebbauser.ger.jdx
    8 -rw-r--r-- 1 fermin staff 1024 May 9 18:30 C:\BBS\msgbase\ebbauser.ger.jhr
    0 -rw-r--r-- 1 fermin staff 0 May 9 18:30 C:\BBS\msgbase\ebbauser.ger.jlr
    0 -rw-r--r-- 1 fermin staff 0 May 9 18:30 C:\BBS\msgbase\essnasa.jdx
    8 -rw-r--r-- 1 fermin staff 1024 May 9 18:30 C:\BBS\msgbase\essnasa.jhr
    0 -rw-r--r-- 1 fermin staff 0 May 9 18:30 C:\BBS\msgbase\essnasa.jlr
    ********

    Is what I'm trying to do even possible? The server would remain on Windows, including a local copy of GoldEd if needed. But I'd like to be able to remotely access the system using a native version of GoldEd on my Mac.

    Regards
    Fermin


    ... Hey @TOFIRST@, watch me pull a Tagline outta this hat.
    --- GoldED+/W64-MSVC 1.1.5-b20180707
    * Origin: 2:301/123 (2:301/123)
  • From Karel Kral@2:423/39 to Fermin Sanchez on Sun May 9 18:50:05 2021
    Hello Fermin!

    09 May 21 18:07, you wrote to All:


    I therefore tried using "MAPPATH" on my Macs golded.cfg to rewrite whatever c:\.... to /Volumes/bbs/....:

    I thought that MAC is like Unix/Linux.

    I am using in golded.areas:

    AREADEF ENET.SYSOP "" B ECHO JAM /home/fido/jam/enet 2:423/39.0 (Loc)

    and it is working smooth.
    (exported by crashmail)

    be able to remotely access the system using a native version of GoldEd
    on my Mac.

    I know is not answer to your question, but - I would not put there "windows syntax" - as my linux see that path completely different = therefor I am using native linux definition (and no some mapping...)

    Karel

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: Plast DATA (2:423/39)
  • From Fermin Sanchez@2:301/123 to Karel Kral on Sun May 9 19:04:33 2021

    Hello Karel!

    09 May 21 18:50, you wrote to me:

    I therefore tried using "MAPPATH" on my Macs golded.cfg to
    rewrite whatever c:\.... to /Volumes/bbs/....:
    I thought that MAC is like Unix/Linux.

    Yup, it's Unix, basically.


    I am using in golded.areas:
    AREADEF ENET.SYSOP "" B ECHO JAM /home/fido/jam/enet 2:423/39.0 (Loc)

    and it is working smooth.
    (exported by crashmail)

    The problem is that my Fido system runs on a Windows server (virtual machine in my basement). So all the definitions/paths, also what gets automatically generated (e.g. areas.bbs and areas.gld) contains c:\bbs\... style paths. I't only the GoldEd that I would like to have running on my Mac.

    be able to remotely access the system using a native version of
    GoldEd on my Mac.
    I know is not answer to your question, but - I would not put there "windows syntax" - as my linux see that path completely different = therefor I am using native linux definition (and no some mapping...)

    I could probably try to do an automatic conversion, using a script, to change the path strings in areas.bbs and areas.gld. Had just hoped that the Path mapping keyword in golded.cfg was an easy, elegant solution to get around having to develop something myself. Oh well..

    Regards
    Fermin


    ... Paper cut; Insulting Tagline.
    --- GoldED+/W64-MSVC 1.1.5-b20180707
    * Origin: 2:301/123 (2:301/123)
  • From Karel Kral@2:423/39 to Fermin Sanchez on Sun May 9 20:09:51 2021
    Hello Fermin!

    09 May 21 19:04, you wrote to me:

    The problem is that my Fido system runs on a Windows server (virtual machine in my basement). So all the definitions/paths, also what gets automatically generated (e.g. areas.bbs and areas.gld) contains
    c:\bbs\... style paths. I't only the GoldEd that I would like to have running on my Mac.

    OK. My cfg says:

    ----------------------------------------------------------------------
    -- DRIVE REMAPPING

    // Network drive mapping (ServerDrive -> WorkstationDrive).
    // NOTE: This is MAINLY used to map drives in AREAFILE's.
    // It won't remap paths given anywhere in GOLDED.CFG.
    ;MAPPATH o: /home/fido
    ;MAPPATH D: Y:
    ;MAPPATH E: Z:
    ;IF UNIX
    ; MAPPATH C:\ /mnt/dos/c/ ; For GoldED/LNX reading AREAFILE's.
    ;ENDIF

    So i understand that is mainly/only for areas. (no other keywords).

    In your case, everything in golded.cfg should be in MAC format, and MAPPATH to be used only to map what areas.bbs has.

    E.g. you need only that one:

    MAPPATH C:\BBS\msgbase\ /Volumes/bbs/msgbase/

    The rest of golded.cfg - MAC format to be used... including path to areas.bbs file.

    Karel

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: Plast DATA (2:423/39)
  • From Kai Richter@2:240/77 to Fermin Sanchez on Mon May 10 09:00:32 2021
    Hello Fermin!

    09 May 21, Fermin Sanchez wrote to Karel Kral:

    The problem is that my Fido system runs on a Windows server (virtual machine in my basement).

    Virtual? That's easy then, setup a virtual *nix machine, move fidonet from windows to that and you have identical path names on your fido system and your mac. ;-)

    I could probably try to do an automatic conversion, using a script, to change the path strings in areas.bbs and areas.gld.

    The mappath keyword is designed to do that.

    For the remaining configuration it would be possible to split the config into different segments. Each segment is a small config file. The small segments are loaded with the include keyword. You could have each owns "master" config on the machines e.g.

    # golded.cfg on the mac machine
    include ~/path.mac
    include ~/gedcol.cfg
    include ~/origins.txt
    include ~/makros.cfg
    include ~/xlat.cfg
    include ~/goldhelp.cfg
    include ~/goldkeys.cfg
    include ~/goldrand.cfg

    # golded.cfg on windows
    include c:\path.windows
    incluee c:\all.those.others

    Or if you prefer the all in one config style then you could use the IF keyword to select for the operation system.

    IF <dos/os2/386>
    ELIF <dos/os2/386>
    ELSEIF <dos/os2/386> (same as ELIF)
    ELSE
    ENDIF

    My docs are outdated, i think UNIX is a valid flag today too. Search the golded reference docs for "if os2" to find the latest options and further examples.

    Regards

    Kai

    --- GoldED+/LNX 1.1.4.7
    * Origin: Monobox (2:240/77)
  • From Fermin Sanchez@2:301/123 to Karel Kral on Mon May 10 10:01:35 2021

    Hello Karel!

    09 May 21 20:09, you wrote to me:

    OK. My cfg says: ----------------------------------------------------------------------
    -- DRIVE REMAPPING
    // Network drive mapping (ServerDrive -> WorkstationDrive).
    // NOTE: This is MAINLY used to map drives in AREAFILE's.
    // It won't remap paths given anywhere in GOLDED.CFG.
    ;MAPPATH o: /home/fido
    ;MAPPATH D: Y:
    ;MAPPATH E: Z:
    ;IF UNIX
    ; MAPPATH C:\ /mnt/dos/c/ ; For GoldED/LNX reading AREAFILE's. ;ENDIF

    Yes, that's what I also found. So far, so clear.

    So i understand that is mainly/only for areas. (no other keywords).

    All other paths in my golded.cfg on my Mac are *nix style paths, e.g. /Volumes/bbs/msgbase/areas.bbs etc.

    In your case, everything in golded.cfg should be in MAC format, and MAPPATH to be used only to map what areas.bbs has.
    E.g. you need only that one:
    MAPPATH C:\BBS\msgbase\ /Volumes/bbs/msgbase/

    Doesn't seem to do anything, unfortunately :-( I will probably automate a script that creates a copy of "areas.bbs" using *nix style paths, then reference that file when connecting from my Mac. A first try with a manually copied/changed areas.bbs looks promising.

    The rest of golded.cfg - MAC format to be used... including path to areas.bbs file.

    Yup, that's what the rest looks like. So far, so good. However, the first time I open "Netmail", I get this:
    *****
    Nodelist missing: c:\bbs\nodelist\NODELIST.127
    *****

    And yes, that's the path of my nodelist on my Windows node system. However, my local golded.cfg on my Mac has this to say about the nodelist:
    *****
    #Nodelist
    NODEPATH /Volumes/bbs/nodelist
    NODELIST nodelist.999
    *****

    This really had me scratching my head, because I couldn't figure out where that was coming from. I then compiled the nodelist (./goldnode -C). So far, so good. Still no clue how the "C:\bbs...." path could have been known to GoldEd.


    Regards
    Fermin


    ... !:*#/g_lqer{ 8ry]@jvBnGkj (Tagline courtesy of two-year-old)
    --- GoldED+/W64-MSVC 1.1.5-b20180707
    * Origin: 2:301/123 (2:301/123)
  • From Karel Kral@2:423/39 to Fermin Sanchez on Mon May 10 12:25:14 2021
    Hello Fermin!

    10 May 21 10:01, you wrote to me:

    Doesn't seem to do anything, unfortunately :-( I will probably
    automate a script that creates a copy of "areas.bbs" using *nix style paths, then reference that file when connecting from my Mac. A first
    try with a manually copied/changed areas.bbs looks promising.

    Anything in LOG then?

    This really had me scratching my head, because I couldn't figure out
    where that was coming from. I then compiled the nodelist (./goldnode
    -C). So far, so good. Still no clue how the "C:\bbs...." path could
    have been known to GoldEd.

    I would find that in my case there: goldnode.gxl

    ;-)

    I mean, without compilation there is/was still old path...

    Karel

    PS: using node on linux machine long time already (but without bbs). I can not imagine moving back to windows...

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: Plast DATA (2:423/39)
  • From Fermin Sanchez@2:301/123 to Karel Kral on Mon May 10 13:49:31 2021

    Hello Karel!

    10 May 21 12:25, you wrote to me:

    Doesn't seem to do anything, unfortunately :-( I will probably
    automate a script that creates a copy of "areas.bbs" using *nix
    style paths, then reference that file when connecting from my
    Mac. A first try with a manually copied/changed areas.bbs looks
    promising.
    Anything in LOG then?

    Nothing, yet. I'll crank up the log level... ;-)

    This really had me scratching my head, because I couldn't figure
    out where that was coming from. I then compiled the nodelist
    (./goldnode -C). So far, so good. Still no clue how the
    "C:\bbs...." path could have been known to GoldEd.
    I would find that in my case there: goldnode.gxl
    ;-)

    D'OH! Yes, of course. Hmm... so this means I'll probably have to differentiate between two "nodelist" directories. Not a big deal - whenever there's a new nodelist I'll copy it to c:\bbs\nodelist and at the same time to c:\bbs\nodelist\mac. Then just point my Mac's golded.cfg to the ".../mac" subdirectory.

    I mean, without compilation there is/was still old path...

    Yup, makes total sense. Thanks!


    PS: using node on linux machine long time already (but without bbs). I
    can not imagine moving back to windows...

    I can't imagine using Windows as a client for work, I'm strictly on a Mac for that. When it comes to servers, though, more on the Windows side and also cloud. And my automation Kung Fu is quite firmly based on Windows, either good old DOS batch and very much in PowerShell. But who knows... ;-)


    Regards
    Fermin


    ... None of these Taglines were sexist or offensive? Where did I go WRONG?
    --- GoldED+/W64-MSVC 1.1.5-b20180707
    * Origin: 2:301/123 (2:301/123)
  • From Matthias Hertzog@2:301/1 to Kai Richter on Tue May 11 17:08:06 2021
    Hi Kai!

    Virtual? That's easy then, setup a virtual *nix machine, move fidonet
    from windows to that and you have identical path names on your fido
    system and your mac. ;-)

    I see, the old OS-wars are still not over in here :-)

    Matthias
    --- GoldED+/W64-MSVC 1.1.5-b20180707
    * Origin: MHS Systems (2:301/1)
  • From Fermin Sanchez@2:301/123 to Kai Richter on Tue May 11 19:38:00 2021

    Hello Kai!

    10 May 21 09:00, you wrote to me:


    The problem is that my Fido system runs on a Windows server
    (virtual machine in my basement).
    Virtual? That's easy then, setup a virtual *nix machine, move fidonet
    from windows to that and you have identical path names on your fido
    system and your mac. ;-)

    Yes, that would indeed be a possible solution. Part of the problem, however, is this:
    <My scripting skills on Windows>
    @echo off
    for %%I in ("%~dp0\..") do set "base=%%~fI"

    TITLE "BinkD"
    %base%\binkd\binkd.exe -C %base%\config\binkd.cfg

    REM Don't get me started on PowerShell, got about 4th Dan black belt ;-)
    </My scripting skills on Windows>

    <My scripting skills on *nix>
    </My scripting skills on *nix>

    I could probably try to do an automatic conversion, using a
    script, to change the path strings in areas.bbs and areas.gld.
    The mappath keyword is designed to do that.

    That's what I tried, didn't work. Probably layer 8 problem, then. I'll try to get some verbose logs...

    For the remaining configuration it would be possible to split the
    config into different segments. Each segment is a small config file.
    The small segments are loaded with the include keyword. You could have each owns "master" config on the machines e.g.

    # golded.cfg on the mac machine
    include ~/path.mac
    include ~/gedcol.cfg
    include ~/origins.txt
    include ~/makros.cfg
    include ~/xlat.cfg
    include ~/goldhelp.cfg
    include ~/goldkeys.cfg
    include ~/goldrand.cfg

    # golded.cfg on windows
    include c:\path.windows
    incluee c:\all.those.others

    Or if you prefer the all in one config style then you could use the IF keyword to select for the operation system.

    IF <dos/os2/386>
    ELIF <dos/os2/386>
    ELSEIF <dos/os2/386> (same as ELIF)
    ELSE
    ENDIF

    Thanks, I'll give this a try!!

    Regards
    Fermin


    ... ..............All's fair in love and Tagline assimilation............... --- GoldED+/W64-MSVC 1.1.5-b20180707
    * Origin: 2:301/123 (2:301/123)
  • From Fermin Sanchez@2:301/123 to Matthias Hertzog on Tue May 11 19:43:38 2021

    Hello Matthias!

    11 May 21 17:08, you wrote to Kai Richter:

    Virtual? That's easy then, setup a virtual *nix machine, move
    fidonet from windows to that and you have identical path names on
    your fido system and your mac. ;-)
    I see, the old OS-wars are still not over in here :-)

    They can be fun... take me for example. I'm a Microsoft Certified *.* (at least it feels that way), also been a Microsoft Certified Trainer for 21 years now. You would *never* get me to use Windows 10 as a client OS if I have the choice. The only Win10 client I barely tolerate is a gaming PC at home. I prefer using Mac OS as a client, and I don't have any problems doing my work on it, even managing Windows server based environments and the MS cloud. All I need is a remote desktop client (Royal TS, but even MS's native "RDP client" for Mac OS isn't too bad), browser (Google Chrome, Safari and MS Edge in my case) and PowerShell. And yes, PowerShell is natively available for Mac OS. As is Office, though Outlook on Mac OS is unfortunately sadly lacking when compared to Outlook on Windows ("Quick steps" are a central part of my workflow, unfortunatly not available on Outlook on Mac). But Word/Excel/PowerPoint/OneNote are more or less identical to their Windows based counterparts.

    At work we have Citrix, and I use published Apps ("XenApp") to get the necessary apps onto Mac OS based desktop. The machine that delivers those apps is Windows Server 2019, not Win10, so I can more or less tolerate it ;-)


    Regards
    Fermin


    ... !:*#/g_lqer{ 8ry]@jvBnGkj (Tagline courtesy of two-year-old)
    --- GoldED+/W64-MSVC 1.1.5-b20180707
    * Origin: 2:301/123 (2:301/123)
  • From Karel Kral@2:423/39 to Fermin Sanchez on Tue May 11 23:53:52 2021
    Hello Fermin!

    11 May 21 19:43, you wrote to Matthias Hertzog:

    central part of my workflow, unfortunatly not available on Outlook on Mac). But Word/Excel/PowerPoint/OneNote are more or less identical to their Windows based counterparts.

    I know nothing about MAC's - I just have to cooperate with these people. And it was not so easy until Teams. (all these Skype FB/Federation issues, not sure why Webex was not so working, etc. And of course they refused for some reasons BlueJeans, Zoom and other platforms...)

    I mean, I do not like Microsoft OS so much as well. But is a business and sometimes I have to do something for living (daily ;-)

    And honestly these Teams really connected "us".

    Karel

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: Plast DATA (2:423/39)
  • From Fermin Sanchez@2:301/123 to Karel Kral on Wed May 12 12:04:56 2021

    Hello Karel!

    11 May 21 23:53, you wrote to me:

    central part of my workflow, unfortunatly not available on
    Outlook on Mac). But Word/Excel/PowerPoint/OneNote are more or
    less identical to their Windows based counterparts.
    I know nothing about MAC's - I just have to cooperate with these
    people. And it was not so easy until Teams. (all these Skype
    FB/Federation issues, not sure why Webex was not so working, etc. And
    of course they refused for some reasons BlueJeans, Zoom and other platforms...)

    I regularily log into WebEx meetings on my Mac, but that has only been the case for the last 7 months or so. Quite possible that Cisco did some tweaking on their Mac client? And we used to have Skype for Business at work, until I was finally able (as in "allowed") to migrate us to Teams. No issues since then, but the SfB client had some stupid limitations on the Mac. I guess "feature parity" for Mac OS on SfB isn't high on Microsoft's priority list, since SfB is more or less a dead platform/product.

    I mean, I do not like Microsoft OS so much as well. But is a business
    and sometimes I have to do something for living (daily ;-)

    Yup, same here. I used to say "I was young and needed the money". The second part still applies, the first... But at least I can do my work from a Mac, which helps with some of the pain. :-)

    And honestly these Teams really connected "us".

    MS Teams is indeed great, feature parity across at leaast Windows and Mac (with some features on Mac maybe 2-3 weeks behind at most, which in most cases isn't a big issue), and not too bad mobile apps, either. There's even a version running natively on Linux (Ubuntu recommended, I think?), not sure how up-to-date that one is compared to the Win and Mac editions. And there's always the Web client, which honestly isn't that far behind, either. I take it MS would prefer people to connect to their services using Windows, but the main point is that people connect to their services and have a cloud subscription. "Cloud first, mobile first" I believe is their mission statement. Seems to be working just fine for them.


    Regards
    Fermin


    ... Copy, S*W*I*P*E, Assimilate ... Do Not Emulate!: The *Tagline Court*
    --- GoldED+/W64-MSVC 1.1.5-b20180707
    * Origin: 2:301/123 (2:301/123)
  • From Karel Kral@2:423/39 to Fermin Sanchez on Wed May 12 18:42:30 2021
    Hello Fermin!

    12 May 21 12:04, you wrote to me:

    MS Teams is indeed great, feature parity across at leaast Windows and
    Mac (with some features on Mac maybe 2-3 weeks behind at most, which
    in most cases isn't a big issue), and not too bad mobile apps, either.

    As we are using Teams on mobilephone in corp enviroment, I had to also install Microsoft inTune (or what was the name). I never seen worse app (worse reputation ever)... But Teams are OK.

    Fancy thing is like you can move seamlessly between notebook client and mobile client (e.g. you are on call and need to leave notebook - it just move it to mobile phone...) Also Subtitles during call are funny. (some people here started to use it for English lessons ;-)

    Karel

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: Plast DATA (2:423/39)
  • From Kai Richter@2:240/77 to Matthias Hertzog on Wed May 12 20:29:24 2021
    Hello Matthias!

    11 May 21, Matthias Hertzog wrote to Kai Richter:

    Virtual? That's easy then, setup a virtual *nix machine, move
    fidonet from windows to that and you have identical path names on
    your fido system and your mac. ;-)

    I see, the old OS-wars are still not over in here :-)

    Not really. :-) Double negative, tricky. Well, he said what the problem is and i suggested a possible solution for that problem. I think goldeds multi os configuration support is good. With a little bit fine tuning it should be possible to create a single configuration file setting that would work with all OS.

    Regards

    Kai

    --- GoldED+/LNX 1.1.4.7
    * Origin: Monobox (2:240/77)
  • From Kai Richter@2:240/77 to Fermin Sanchez on Wed May 12 20:43:36 2021
    Hello Fermin!

    11 May 21, Fermin Sanchez wrote to Kai Richter:

    Yes, that would indeed be a possible solution. Part of the problem, however, is this: <My scripting skills on Windows>

    Alternate solution: Setup ssh and use your windows golded via terminal.

    Regards

    Kai

    --- GoldED+/LNX 1.1.4.7
    * Origin: Monobox (2:240/77)
  • From Fermin Sanchez@2:301/123 to Karel Kral on Thu May 13 00:22:04 2021

    Hello Karel!

    09 May 21 20:09, you wrote to me:

    OK. My cfg says:

    ----------------------------------------------------------------------
    -- DRIVE REMAPPING

    // Network drive mapping (ServerDrive -> WorkstationDrive).
    // NOTE: This is MAINLY used to map drives in AREAFILE's.
    // It won't remap paths given anywhere in GOLDED.CFG.
    ;MAPPATH o: /home/fido
    ;MAPPATH D: Y:
    ;MAPPATH E: Z:
    ;IF UNIX
    ; MAPPATH C:\ /mnt/dos/c/ ; For GoldED/LNX reading AREAFILE's. ;ENDIF

    I think I see what the problem is. The whole Fidonet node system is on c:\bbs on my Windows server. I have created a share "bbs" directly in that folder. Therefore, when I map smb://<server>/smb to /Volumes/smb on my Mac, what I see as root of that share is in fact a subfolder of C:\ on the server. To use mappath I would need to map smb://<server>/c to /Volumes/c on my Mac. There are various reasons I'm unwilling to do that, not least because I don't want to expose the whole OS drive on a remote system.

    I had tried this with MAPPATH:
    MAPPATH C:\bbs /Volumes/bbs

    However, this is what would probably work:
    MAPPATH C:\ /Volumes/c

    Too bad.

    Regards
    Fermin


    ... Oooh, this ISN'T the Tagline Conference??!! <*cringe*>
    --- GoldED+/W64-MSVC 1.1.5-b20180707
    * Origin: 2:301/123 (2:301/123)
  • From Matthias Hertzog@2:301/1 to Kai Richter on Thu May 13 11:07:15 2021
    Hello Kai!

    Alternate solution: Setup ssh and use your windows golded via
    terminal.

    I've tried that as well, but failed with the OpenSSH installation. "Gebaschtel" on windows. Do you have that running like that?

    Matthias
    --- GoldED+/W64-MSVC 1.1.5-b20180707
    * Origin: MHS Systems (2:301/1)
  • From Fermin Sanchez@2:301/123 to Kai Richter on Thu May 13 12:33:39 2021

    Hello Kai!

    12 May 21 20:43, you wrote to me:

    Yes, that would indeed be a possible solution. Part of the
    problem, however, is this: <My scripting skills on Windows>
    Alternate solution: Setup ssh and use your windows golded via
    terminal.

    I'll probably end up using something similar. Thinking of publishing GoldEd as a Terminal Services remote app. Even on Mac, I could then just run the program via RDP, no need to connect to the whole desktop.

    If I start playing around with SSH that means I'll transfer the whole thing onto a Linux VM and use SSH from my Mac to connect and launch GoldEd. Or even start GoldEd remotely. About that (running GoldEd remotely), by the way, it looks like I have run into the next possible show stopper. This didn't happen before, but now I get this when I try to get out of an Area on GoldEd running remotely on my Mac:

    *****
    Wait: /Volumes/bbs/msgbase/region30 is locked
    *****

    Not sure what that is all about?

    Regards
    Fermin


    ... ( ( ( ( ( ((Stereo Tagline)) ) ) ) ) )
    --- GoldED+/W64-MSVC 1.1.5-b20180707
    * Origin: USS Ferminator - Unteraegeri, Switzerland (2:301/123)
  • From Kai Richter@2:240/77 to Fermin Sanchez on Thu May 13 10:04:48 2021
    Hello Fermin!

    13 May 21, Fermin Sanchez wrote to Karel Kral:

    ; MAPPATH C:\ /mnt/dos/c/ ; For GoldED/LNX reading

    To use mappath I would need to map smb://<server>/c to /Volumes/c on
    my Mac. There are various reasons I'm unwilling to do that, not least because I don't want to expose the whole OS drive on a remote system.

    I solved that issue by moving the fido installation into it's own drive letter. You could share c:\bbs to x:\ on the windows server. All config references would move from c:\bbs to x:\ and fido would start at x:\ as working dir.

    I had tried this with MAPPATH:
    MAPPATH C:\bbs /Volumes/bbs

    What about UNC names? Another approach is to target the files directly without use of the mounting mechanism. //server/share/path is a valid adress in the windows file explorer.

    This reminds me to the escape chars in some *nix shells. "echo \n" displays "n" instead of "\n". To see "\n" you have to say "echo \\n".

    Increase the loglevel and look if golded tells you what it does really use for path names.

    Regards

    Kai

    --- GoldED+/LNX 1.1.4.7
    * Origin: Monobox (2:240/77)
  • From Kai Richter@2:240/77 to Matthias Hertzog on Fri May 14 11:22:58 2021
    Hello Matthias!

    13 May 21, Matthias Hertzog wrote to Kai Richter:

    Alternate solution: Setup ssh and use your windows golded via
    terminal.

    I've tried that as well, but failed with the OpenSSH installation. "Gebaschtel" on windows. Do you have that running like that?

    No but vice versa. The sshd is on a linux machine and the client is windows putty. I never tried the reverse way, sorry.

    Regards

    Kai

    --- GoldED+/LNX 1.1.4.7
    * Origin: Monobox (2:240/77)
  • From Kai Richter@2:240/77 to Fermin Sanchez on Fri May 14 12:20:46 2021
    Hello Fermin!

    13 May 21, Fermin Sanchez wrote to Kai Richter:

    I'll probably end up using something similar. Thinking of publishing GoldEd as a Terminal Services remote app. Even on Mac, I could then
    just run the program via RDP, no need to connect to the whole desktop.

    Interesting approach.

    show stopper. This didn't happen before, but now I get this when I try
    to get out of an Area on GoldEd running remotely on my Mac:

    *****
    Wait: /Volumes/bbs/msgbase/region30 is locked
    *****

    Not sure what that is all about?

    I'm not sure if that's a filesystem message or a msgbase issue. Do you have r/w access to the files? Does the username match? Some sharing tools offer a usermap feature that tells the server that the remote "mac" username is equal to the local "windows" username.

    The msgbases are not multi access approved. If a tosser is active the area should be locked to prevent the editor to mess up the tossing run. I would look for other running sessions. How does the terminal service remote app from above work? A service is running in background all the time?

    If all fails the last option would be a point installation on the mac that connects to the node on windows via mailer.

    Regards

    Kai

    --- GoldED+/LNX 1.1.4.7
    * Origin: Monobox (2:240/77)
  • From Fermin Sanchez@2:301/123 to Kai Richter on Sat May 15 02:03:52 2021

    Hello Kai!

    14 May 21 12:20, you wrote to me:

    I'll probably end up using something similar. Thinking of
    publishing GoldEd as a Terminal Services remote app. Even on Mac,
    I could then just run the program via RDP, no need to connect to
    the whole desktop.
    Interesting approach.

    It's the "Windows style" of doing things. I've just moved my whole fido setup to a new drive on my Windows terminal server, now everything is under f:/fido. And I'm typing this on my Mac, but in GoldEd+/W64, published as a single window via RDP. The client needed to connect is Microsoft's own "Microsoft Remote Desktop" which is natively available on Mac.

    show stopper. This didn't happen before, but now I get this when
    I try to get out of an Area on GoldEd running remotely on my Mac:
    *****
    Wait: /Volumes/bbs/msgbase/region30 is locked
    *****
    Not sure what that is all about?

    I'm not sure if that's a filesystem message or a msgbase issue. Do you have r/w access to the files? Does the username match? Some sharing
    tools offer a usermap feature that tells the server that the remote
    "mac" username is equal to the local "windows" username.

    Yes, the names match, and I do have full access with my user. It's quite strange, I also initally had this when using terminal services with the "RemoteApp" version of GoldEd. Seems to be working now, though.

    The msgbases are not multi access approved. If a tosser is active the
    area should be locked to prevent the editor to mess up the tossing
    run. I would look for other running sessions. How does the terminal service remote app from above work? A service is running in background
    all the time?

    There shouldn't have been any other running sessions, at least I'm not aware of any. Very curious, indeed. And I've had GoldEd open in the past few days on my node system while new mail came in and the tosser (Fmail) went to work. So you're suggesting I should prevent that from being possible by using semaphore flags?

    If all fails the last option would be a point installation on the mac
    that connects to the node on windows via mailer.

    Yes, also an option. But I'll try some more with this (terminal server RemoteApp etc.) approach. "How hard can it be", as Mr Clarkson uses to say... ;-)


    Regards
    Fermin


    ... Other Taglines will follow...Keep only the ones you want...
    --- GoldED+/W64-MSVC 1.1.5-b20180707
    * Origin: USS Ferminator - Unteraegeri, Switzerland (2:301/123)
  • From Matthias Hertzog@2:301/1 to Kai Richter on Sat May 15 15:01:10 2021
    Hello Kai!

    I've tried that as well, but failed with the OpenSSH
    installation. "Gebaschtel" on windows. Do you have that running
    like that?
    No but vice versa. The sshd is on a linux machine and the client is windows putty.

    Agree.

    I never tried the reverse way, sorry.

    I've tried and i regret it. But no longer needed here.

    Matthias
    --- GoldED+/W64-MSVC 1.1.5-b20180707
    * Origin: MHS Systems (2:301/1)
  • From Kai Richter@2:240/77 to Fermin Sanchez on Sat May 15 20:40:10 2021
    Hello Fermin!

    15 May 21, Fermin Sanchez wrote to Kai Richter:

    with the "RemoteApp" version of GoldEd. Seems to be working now,

    Then what ever you do, do not touch it! ;-)

    The msgbases are not multi access approved. If a tosser is active
    the area should be locked to prevent the editor to mess up the
    tossing run.

    I've had GoldEd open in the past few days on my node system while new
    mail came in and the tosser (Fmail) went to work. So you're
    suggesting I should prevent that from being possible by using
    semaphore flags?

    I recommend to take a closer look. Maybe everything is fine when golded is in the area list mode without an open area. Or if you use single *.msg echoareas.

    Regards

    Kai

    --- GoldED+/LNX 1.1.4.7
    * Origin: Monobox (2:240/77)
  • From Fermin Sanchez@2:301/123 to Kai Richter on Sat May 15 23:11:48 2021

    Hello Kai!

    15 May 21 20:40, you wrote to me:

    with the "RemoteApp" version of GoldEd. Seems to be working now,
    Then what ever you do, do not touch it! ;-)

    That is indeed very good advice. On the other hand - where's the fun in that? ;-)

    The msgbases are not multi access approved. If a tosser is
    active the area should be locked to prevent the editor to mess
    up the tossing run.

    I've had GoldEd open in the past few days on my node system while
    new mail came in and the tosser (Fmail) went to work. So you're
    suggesting I should prevent that from being possible by using
    semaphore flags?

    I recommend to take a closer look. Maybe everything is fine when
    golded is in the area list mode without an open area. Or if you use
    single *.msg echoareas.

    I use *.msg for Netmail and "personal mail" (FMail copies Echomail addressed to me there), then three areas only in Hudson format (Bad, Dupes and Recovery - also apparently the FMail way to create those areas). The rest are JAM format. But thanks for the advice, I'll definitely look into this.

    Regards
    Fermin


    ... Ranked in accordance with Winslow Tagline Rate-O-Meter(tm).
    --- GoldED+/W64-MSVC 1.1.5-b20180707
    * Origin: USS Ferminator - Unteraegeri, Switzerland (2:301/123)
  • From Karel Kral@2:423/39 to Fermin Sanchez on Sun May 16 06:28:59 2021
    Hello Fermin!

    15 May 21 23:11, you wrote to Kai Richter:

    I use *.msg for Netmail and "personal mail" (FMail copies Echomail addressed to me there), then three areas only in Hudson format (Bad,
    Dupes and Recovery - also apparently the FMail way to create those
    areas). The rest are JAM format. But thanks for the advice, I'll definitely look into this.

    I have similar setup (just - instead of fmail using crashmail and - using linux ;-) and Golded can live with tosser touching JAM and msg on the background. For example: reading echo, tosser add messages, tells Golded to rescan via flag, and I see new message immediately (no visible locking). But - not tested to "write" or better to say "save" message during tossing. Due to the very short timing - is very hard to even simulate.

    Karel

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: Plast DATA (2:423/39)
  • From Fermin Sanchez@2:301/123 to Karel Kral on Sun May 16 09:45:19 2021

    Hello Karel!

    16 May 21 06:28, you wrote to me:

    I use *.msg for Netmail and "personal mail" (FMail copies
    Echomail addressed to me there), then three areas only in Hudson
    format (Bad, Dupes and Recovery - also apparently the FMail way
    to create those areas). The rest are JAM format. But thanks for
    the advice, I'll definitely look into this.
    I have similar setup (just - instead of fmail using crashmail and -
    using linux ;-) and Golded can live with tosser touching JAM and msg
    on the background. For example: reading echo, tosser add messages,
    tells Golded to rescan via flag, and I see new message immediately (no visible locking). But - not tested to "write" or better to say "save" message during tossing. Due to the very short timing - is very hard to even simulate.

    I remember when tossing messages and compiling the nodelist (Goldnode) would take a noticeable amount of time. It was quite a pleasant shock how fast this software runs on modern hardware.

    I'll look into the "flags" thing, thanks! I usually have a "tail" window of BinkD running and see if something comes in, then just use "Alt"+"S" to rescan. But why do something manually if the system works for you...

    Regards
    Fermin


    ... I'm too sexy for this Tagline.
    --- GoldED+/W64-MSVC 1.1.5-b20180707
    * Origin: USS Ferminator - Unteraegeri, Switzerland (2:301/123)
  • From Kai Richter@2:240/77 to Karel Kral on Sun May 16 09:20:42 2021
    Hello Karel!

    16 May 21, Karel Kral wrote to Fermin Sanchez:

    using linux ;-) and Golded can live with tosser touching JAM and msg
    on the background.

    I'm on squish and i can remember golded telling me a squish "area is locked please wait" then stay in an endless waiting counter.

    But - not tested to "write" or better to say "save" message during tossing.

    I don't know the exact golded process flow. I know that golded does temporary local backup writes of the open message for edit. The unsaved message is placed in the file golded.msg. If golded crashes with a 10k unsaved message it would call out "unfinished mail found" when you create a new message and the 10k-x text of the unsaved message is still there.

    That's why i think the real write access time to the msgbase is very short. On the other hand the question is what the tosser would do on a locked msgarea. Wait for access? Skip? Where is the skipped mail? Still in the pkt? In some temp spools? In the badmail area?

    Regards

    Kai

    --- GoldED+/LNX 1.1.4.7
    * Origin: Monobox (2:240/77)
  • From Kai Richter@2:240/77 to Fermin Sanchez on Sun May 16 09:49:00 2021
    Hello Fermin!

    15 May 21, Fermin Sanchez wrote to Kai Richter:

    while new mail came in and the tosser (Fmail) went to work. So
    you're suggesting I should prevent that from being possible by
    using semaphore flags?

    My personal setting is like that. If golded is open the tosser scan for new mail is blocked. But the main reason is my bad spelling skill. I like to read a mail again after saving because i found some typos all the time.

    (skills corrected after first saving. I have one spelling skill only. And it's getting me down. ;-) )

    My favorite typo atm is akutal vs aktual. It does not happen with the english actual, i've no idea why... Anyway, the semaphore inhibits the tosser stealing the message from my fingertips. The disadvantage is that any outgoing traffic is paused. Because i don't have downlinks that's fine but this would not be a good solution for hub systems.

    Regards

    Kai

    --- GoldED+/LNX 1.1.4.7
    * Origin: Monobox (2:240/77)
  • From Karel Kral@2:423/39 to Kai Richter on Sun May 16 14:00:06 2021
    Hello Kai!

    16 May 21 09:49, you wrote to Fermin Sanchez:

    My personal setting is like that. If golded is open the tosser scan
    for new mail is blocked. But the main reason is my bad spelling skill.
    I like to read a mail again after saving because i found some typos
    all the time.

    Same here. But is like "until tosser get flag from GoldEd is not scanning". And that flag creates GoldEd only on exit. In different words - Crashmail can toss, but not scan until specific flag is there.

    In GoldEd itself I can change message safely until there is Unsent Flag. At the end, when I exit GoldEd, everything is scanned, packed and in one session sent to my uplink... (saving overhead of transfers, but OK, nowadays does not matter...)

    Karel

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: Plast DATA (2:423/39)
  • From Karel Kral@2:423/39 to Kai Richter on Sun May 16 14:10:43 2021
    Hello Kai!

    16 May 21 09:20, you wrote to me:

    That's why i think the real write access time to the msgbase is very short. On the other hand the question is what the tosser would do on a locked msgarea. Wait for access? Skip? Where is the skipped mail?
    Still in the pkt? In some temp spools? In the badmail area?

    It is probably very specific. I checked source code for Crashmail (ok, version 1.6 here, file src/jamlib/jamlib.doc - but OK):

    -------
    if ( Result_I == JAM_LOCK_FAILED )
    /* base locked by someone else, wait for unlock */
    sleep( 1 );
    -------
    So Crashmail should wait until GoldEd unlock it...

    Karel

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: Plast DATA (2:423/39)