• LHZ/LZH for Windows (typo?), 7Z for Linux, and viewing of LZH and ARJ

    From Björn Wiberg@2:201/137 to g00r00 on Mon Aug 2 09:45:02 2021
    Hello g00r00!

    I just noticed that in the Archive Editor --> Ext LHZ, for Windows, with Description "LHZ (via 7-ZIP)" perhaps should be Ext LZH with Description "LZH
    (via 7-ZIP)" instead? Or does the file extension for those archives differ on the Windows platform? Not sure...

    Furthermore, I would suggest adding an archiver entry 7Z (7-ZIP) for Linux to complement the existing one for Windows, or perhaps simply changing the OS to All if it has the same syntax also for MacOS?

    Finally -- I'm having trouble viewing ARJ and LZH/LHA archives on Linux x86_64. For LZH/LHA the archive viewer simply views no content. For ARJ it emits "Unable to view archive" (prompt #191).

    I notice that some archive formats have a View Cmd specified, but that is not the case for ARJ or LZH/LHA. Does this mean that the viewer is internal to Mystic? Do you perhaps have some working View Cmd lines for ARJ and LZH/LHA, if that can be used?

    Thanks in advance!

    Best regards
    Bj”rn

    --- Mystic BBS v1.12 A47 2021/07/31 (Linux/64)
    * Origin: Star Collision BBS, Uppsala, Sweden (2:201/137)
  • From g00r00@1:129/215 to Björn Wiberg on Mon Aug 2 10:04:22 2021
    I just noticed that in the Archive Editor --> Ext LHZ, for Windows, with Description "LHZ (via 7-ZIP)" perhaps should be Ext LZH with Description

    Thanks I'll fix that.

    Furthermore, I would suggest adding an archiver entry 7Z (7-ZIP) for
    Linux to complement the existing one for Windows, or perhaps simply changing the OS to All if it has the same syntax also for MacOS?

    You are free to do that if you'd like and send it along. I'll make a note of it in my TODO list in the meantime just don't know when I might get around to it.

    I notice that some archive formats have a View Cmd specified, but that
    is not the case for ARJ or LZH/LHA. Does this mean that the viewer is internal to Mystic? Do you perhaps have some working View Cmd lines for ARJ and LZH/LHA, if that can be used?

    Mystic does have interval code specifically for ZIP, RAR, and LZH/LHA which is how its able to provide the advanced type of archive functions/viewing that Mystic can do. If you find a LZH/LHA file that you cannot view feel free to e-mail it to me so I can take a look at it.

    There is no enabled setup for ARJ by default in Mystic but if you want to create a view default feel free to do so and send it over, like any other archiver.

    ARJ itself has barely been updated in decades, its not free, and is vastly inherior to other open/free archive alternatives. If I am not mistaken if you download the latest version it will have a 1 minute pause (unless you pay) every time its executed which renders it pretty much useless. You're better off not using ARJ and converting your files to something else that has better compression, secruity, and isn't bound by crippleware.

    Mystic used to have internal ARJ support too when it was more viable but I removed it at some point.

    ... If you choose not to decide, you still have made a choice

    --- Mystic BBS v1.12 A47 2021/07/31 (Windows/64)
    * Origin: Sector 7 * Mystic WHQ (1:129/215)
  • From Björn Wiberg@2:201/137 to g00r00 on Mon Aug 2 20:20:02 2021
    Hello g00r00!

    Thank you for your reply!

    Furthermore, I would suggest adding an archiver entry 7Z (7-ZIP) for Linux to complement the existing one for Windows, or perhaps simply

    You are free to do that if you'd like and send it along. I'll make a
    note of it in my TODO list in the meantime just don't know when I might get around to it.

    This was what I am experimenting with:

    Active ³ Yes
    Extension ³ 7Z
    OS ³ Linux
    Description ³ CUSTOM: 7-ZIP
    Pack Cmd ³ 7z a -y "%1" "%2"
    Unpack Cmd ³ 7z e -y -o"%3" "%1" "%2"
    View Cmd ³ 7z l -y "%1" >> "%3%2"

    The output from 7z, however, does not seem to be very well suited for formatted display, as it includes a lot of diagnostics.

    And the first time you (V)iew it, a red cursor from the File Listing might turn all content output red. :)

    The extraneous output can be skipped with an undocumented -ba switch (see https://stackoverflow.com/a/61654375), yielding output on the form:

    2021-08-02 19:33:08 ....A 5 9 test.txt

    ...however Mystic displays nothing then, so perhaps it is expecting something more than just simple lines like that (and possibly in a different format).

    Like you say, perhaps something for the future... I think I'll ditch the viewing experiment for now. :)

    (I wonder if it is working on Windows? One would think that output should be similar there, with similar problems...)

    Perhaps it might be a good idea to configure the archiver for all *but* viewing, so that it at least can be used for compressed file lists, QWK packets etc.

    functions/viewing that Mystic can do. If you find a LZH/LHA file that
    you cannot view feel free to e-mail it to me so I can take a look at it.

    Sure, this was the one I tested with:

    https://sourceforge.net/projects/thegwolibrary/files/gwo-winxp/gwo0.11/gwo0.11- sample-win32.lzh/download

    There is no enabled setup for ARJ by default in Mystic but if you want to create a view default feel free to do so and send it over, like any other archiver.

    Tried getting this to work, but didn't quite succeed --

    Tried with:

    View Cmd ³ arj l -y "%1"

    ...which resulted in:

    ARJ32 v 3.10, Copyright (c) 1998-2004, ARJ Software Russia.

    Processing archive: /mnt/bbs/mystic/files/local/uploads/a.arj
    Archive created: 2021-08-02 08:35:46, modified: 2021-08-02 08:35:46
    0 file(s)

    Unable to view archive.

    ...and:

    View Cmd ³ arj l -y "%1" >> "%3%2"

    ARJ32 v 3.10, Copyright (c) 1998-2004, ARJ Software Russia.

    Processing archive: /mnt/bbs/mystic/files/local/uploads/a.arj
    Archive created: 2021-08-02 08:35:46, modified: 2021-08-02 08:35:46
    0 file(s)

    Found 1 error(s)!

    I guess >> "%3%2" should redirect output to a temporary file, and Mystic's archive viewer reads that (if it exists).

    Are there any specs on what kind of output format it can "parse"?
    Because I guess all archivers are different?

    Otherwise I'll stick with non-viewing of ARJ archives for the time being (but enabled the archiver to be able to pack/unpack for stuff like file lists and QWK). :)

    Best regards
    Bj”rn
    --- Mystic BBS v1.12 A47 2021/07/31 (Linux/64)
    * Origin: Star Collision BBS, Uppsala, Sweden (2:201/137)
  • From Björn Wiberg@2:201/137 to g00r00 on Tue Aug 3 16:36:24 2021
    Hello g00r00!

    ARJ and 7-ZIP revisited. :)

    On 02 Aug 2021, Bj”rn Wiberg said the following...
    There is no enabled setup for ARJ by default in Mystic but if you wan create a view default feel free to do so and send it over, like any o archiver.

    Tried getting this to work, but didn't quite succeed --

    I performed an strace and noticed that Mystic appears to add "/dev/null 2>&1" to the end of the View Cmd command line. This seems to break things. But on Linux, it is possible to perform the following work-around:

    Active ³ Yes
    Extension ³ ARJ
    OS ³ Linux
    Description ³ ARJ32 ARJ Utilities (CUSTOM)
    Pack Cmd ³ arj a -e -i -y "%1" "%2"
    Unpack Cmd ³ arj e -e -i -y -w"%3" "%1" "%2"
    View Cmd ³ arj l -i -y "%1" >> "%3%2" 2> /dev/null; exit $? >>

    This will preserve the exit status of arj and tame the added /dev/null 2>&1 stuff.

    The -i will remove any progress indicator from the output. Unsure if that one actually shows during viewing, as I haven't checked the source code, but it won't hurt, and it is at least good for packing/unpacking, I presume.

    Also note that there should be no space between -w and "%3"; it appears to be the same thing for other platforms. Otherwise ARJ might complain and interpret the work directory as an archive file name.

    And something similar for 7-ZIP:

    Active ³ Yes
    Extension ³ 7Z
    OS ³ Linux
    Description ³ 7-ZIP (CUSTOM)
    Pack Cmd ³ 7z a -y "%1" "%2"
    Unpack Cmd ³ 7z e -y -o"%3" "%1" "%2"
    View Cmd ³ 7z l -ba -y "%1" >> "%3%2" 2> /dev/null; exit $? >>

    D.S.

    All comments and thoughts welcome. :)

    Best regards
    Bj”rn
    --- Mystic BBS v1.12 A47 2021/07/31 (Linux/64)
    * Origin: Star Collision BBS, Uppsala, Sweden (2:201/137)
  • From Björn Wiberg@2:201/137 to g00r00 on Tue Aug 3 23:51:14 2021
    Hello g00r00!

    Just a quick follow-up on this (in case someone else is also adjusting their archiver configurations, and to write it down) --

    On 03 Aug 2021, Bj”rn Wiberg said the following...
    Pack Cmd ³ arj a -e -i -y "%1" "%2"
    Unpack Cmd ³ arj e -e -i -y -w"%3" "%1" "%2"
    View Cmd ³ arj l -i -y "%1" >> "%3%2" 2> /dev/null; exit $? >>

    Those should be:

    Pack Cmd ³ arj a -e -i -y "%1" "%2" >>
    Unpack Cmd ³ arj e -e -i -y -w"%3" "%1" "%2" >>
    View Cmd ³ arj l -i -y "%1" >> "%3%2" 2> /dev/null; exit $? >>

    Note the added >> to chain with Mystic's addition of /dev/null etc.
    Otherwise arj will interpret /dev/null as an additional filename.

    Pack Cmd ³ 7z a -y "%1" "%2"
    Unpack Cmd ³ 7z e -y -o"%3" "%1" "%2"
    View Cmd ³ 7z l -ba -y "%1" >> "%3%2" 2> /dev/null; exit $? >>

    Those should be:

    Pack Cmd ³ 7z a -ba -y "%1" "%2" >>
    Unpack Cmd ³ 7z e -ba -y -o"%3" "%1" "%2" >>
    View Cmd ³ 7z l -ba -y "%1" >> "%3%2" 2> /dev/null; exit $? >>

    Note the added -ba to get rid of CPU stats etc, and >> to chain with Mystic's addition of /dev/null etc. Otherwise 7z will interpret /dev/null as an additional filename.

    All this makes me wonder if the other archivers would need the same thing (>>)? Or if perhaps this should have been added by Mystic instead?

    I found the following in whatsnew.txt:

    + When executing archives, MUTIL in Unix will now automatically append
    " /dev/null 2>&1" to the end of each archive execution command in order
    to hide standard output and error messages. It was already adding "2>nul"
    in Windows.

    Perhaps this should have been ">> /dev/null 2>&1" instead?

    Best regards
    Bj”rn

    --- Mystic BBS v1.12 A47 2021/07/31 (Linux/64)
    * Origin: Star Collision BBS, Uppsala, Sweden (2:201/137)
  • From g00r00@1:129/215 to Björn Wiberg on Tue Aug 3 23:08:08 2021
    I guess >> "%3%2" should redirect output to a temporary file, and
    Mystic's archive viewer reads that (if it exists).

    Are there any specs on what kind of output format it can "parse"?
    Because I guess all archivers are different?

    Correct for external/unsupported archive formats, Mystic executes the view command line, and then displays the file at %3%2. There is nothing to parse it just displays whatever the view command puts in that file.

    Its allows you to use the archive utility itself to create a listing, or any other utility to do so.

    ... I wish life had a scroll-back buffer.

    --- Mystic BBS v1.12 A47 2021/07/31 (Windows/64)
    * Origin: Sector 7 * Mystic WHQ (1:129/215)
  • From Björn Wiberg@2:201/137 to g00r00 on Wed Aug 4 09:48:20 2021
    Hello g00r00!

    Thank you for your reply!

    On 03 Aug 2021, g00r00 said the following...
    Correct for external/unsupported archive formats, Mystic executes the
    view command line, and then displays the file at %3%2. There is nothing to parse it just displays whatever the view command puts in that file.

    Thanks! Yep, that's the only way to do it.

    Best regards
    Zip

    --- Mystic BBS v1.12 A47 2021/07/31 (Linux/64)
    * Origin: Star Collision BBS, Uppsala, Sweden (2:201/137)
  • From Björn Wiberg@2:201/137 to g00r00 on Wed Aug 4 09:51:12 2021
    Hello g00r00!

    On 03 Aug 2021, Bj”rn Wiberg said the following...
    + When executing archives, MUTIL in Unix will now automatically append
    " /dev/null 2>&1" to the end of each archive execution command in
    order to hide standard output and error messages. It was already adding "2>nul" in Windows.

    Perhaps this should have been ">> /dev/null 2>&1" instead?

    ...or rather " >> /dev/null 2>&1" with a space at the beginning -- to avoid a trailing number (no matter how improbable) to become combined with the >>, redirecting to the specified file descriptor (number)...

    Best regards
    Zip

    --- Mystic BBS v1.12 A47 2021/07/31 (Linux/64)
    * Origin: Star Collision BBS, Uppsala, Sweden (2:201/137)
  • From Björn Wiberg@2:201/137 to g00r00 on Wed Aug 4 11:04:04 2021
    Hello g00r00!

    Revised the command lines some more... To summarize, this seems to work:

    Active ³ Yes
    Extension ³ 7Z
    OS ³ Linux
    Description ³ 7-ZIP
    Pack Cmd ³ 7z a -ba -y "%1" "%2" >>
    Unpack Cmd ³ 7z e -ba -y -o"%3" "%1" "%2" >>
    View Cmd ³ 7z l -y "%1" >> "%3%2" 2> /dev/null; exit $? >>

    Notice the skipping of -ba for viewing as the headers produced by 7z are actually somewhat useful for the user.

    Active ³ Yes
    Extension ³ ARJ
    OS ³ Linux
    Description ³ ARJ32 ARJ Utilities
    Pack Cmd ³ arj a -e -i -y "%1" "%2" >>
    Unpack Cmd ³ arj e -e -i -y -w"%3" -ht"%3" "%1"
    View Cmd ³ arj l -i -y "%1" >> "%3%2" 2> /dev/null; exit $? >>

    Notice the need for -ht during unpacking to avoid unpacking files into the current working directory (= the Mystic base directory) of Mystic. This
    would be needed for the default/stock "All" OS version, too.

    Finally, the differing coloring of the viewing output can be fixed by adding a somewhat "neutral" color switch (e.g. PIPE 07) to the end of prompts #432 and #433 (some of the lightbar file list prompts).

    Hoping some of this will be useful for future versions of Mystic (and for others experimenting in the mean time)!

    Best regards
    Bj”rn

    --- Mystic BBS v1.12 A47 2021/07/31 (Linux/64)
    * Origin: Star Collision BBS, Uppsala, Sweden (2:201/137)
  • From Björn Wiberg@2:201/137 to g00r00 on Wed Aug 4 11:20:12 2021
    Hello g00r00 (and others)!

    Of course I forgot one thing...

    On 04 Aug 2021, Bj”rn Wiberg said the following...
    Finally, the differing coloring of the viewing output can be fixed by adding a somewhat "neutral" color switch (e.g. PIPE 07) to the end of prompts #432 and #433 (some of the lightbar file list prompts).

    ...and to the end of #304, the archive view command prompt (applies if you press (R)e-list).

    Best regards
    Bj”rn

    --- Mystic BBS v1.12 A47 2021/07/31 (Linux/64)
    * Origin: Star Collision BBS, Uppsala, Sweden (2:201/137)
  • From g00r00@1:129/215 to Björn Wiberg on Wed Aug 4 11:35:10 2021
    Perhaps this should have been ">> /dev/null 2>&1" instead?

    Yes maybe it should have been "> /dev/null 2>&1" and I didn't put the > in there. I'll try adding that in.

    ... The reason Santa is so jolly is because he knows where the bad girls live

    --- Mystic BBS v1.12 A47 2021/07/31 (Windows/64)
    * Origin: Sector 7 * Mystic WHQ (1:129/215)
  • From Björn Wiberg@2:201/137 to g00r00 on Wed Aug 4 19:00:48 2021
    Hello g00r00!

    Thank you for your reply!

    On 04 Aug 2021, g00r00 said the following...
    Yes maybe it should have been "> /dev/null 2>&1" and I didn't put the >
    in there. I'll try adding that in.

    Thanks a lot!

    (Please let me know once it's added, and I'll help you try it out!)

    Best regards
    Bj”rn
    --- Mystic BBS v1.12 A47 2021/07/31 (Linux/64)
    * Origin: Star Collision BBS, Uppsala, Sweden (2:201/137)
  • From g00r00@1:129/215 to Björn Wiberg on Wed Aug 4 23:46:42 2021
    ...or rather " >> /dev/null 2>&1" with a space at the beginning -- to

    I changed it to add " > /dev/null 2>&1" now but I have not done any testing yet.

    I did notice that adding the quotes around "%3" in the unzip command did cause a problem so I did revert that.

    ... Press SPACEBAR once to abort, or twice to save changes
    --- Mystic BBS v1.12 A47 2021/07/31 (Windows/64)
    * Origin: Sector 7 * Mystic WHQ (1:129/215)
  • From Björn Wiberg@2:201/137 to g00r00 on Thu Aug 5 09:13:18 2021
    Hello g00r00!

    Thank you for your reply!

    I changed it to add " > /dev/null 2>&1" now but I have not done any testing yet.

    Sounds great!

    I did notice that adding the quotes around "%3" in the unzip command did cause a problem so I did revert that.

    Strange... Did you try running it manually (and without the q:s) also to see what the error message was?

    (Tried it from the command line here and it seemed to work fine...)

    Best regards
    Bj”rn
    --- Mystic BBS v1.12 A47 2021/07/31 (Linux/64)
    * Origin: Star Collision BBS, Uppsala, Sweden (2:201/137)
  • From g00r00@1:129/215 to Björn Wiberg on Thu Aug 5 11:11:12 2021
    Yes maybe it should have been "> /dev/null 2>&1" and I didn't put the in there. I'll try adding that in.

    Thanks a lot!

    (Please let me know once it's added, and I'll help you try it out!)

    I have uploaded a new version let me know how it goes so I can quickly replace it if its broken! :)

    ... What does it mean to pre-board? Do you get on before you get on?

    --- Mystic BBS v1.12 A47 2021/07/31 (Windows/64)
    * Origin: Sector 7 * Mystic WHQ (1:129/215)
  • From Björn Wiberg@2:201/137 to g00r00 on Thu Aug 5 22:20:08 2021
    Hello g00r00!

    Thank you for your reply!

    On 05 Aug 2021, g00r00 said the following...
    Yes maybe it should have been "> /dev/null 2>&1" and I didn't pu in there. I'll try adding that in.
    (Please let me know once it's added, and I'll help you try it out!)

    I have uploaded a new version let me know how it goes so I can quickly replace it if its broken! :)

    Thanks a lot! Seems to be working fine!

    I checked the executions with strace, and they look perfectly fine, e.g.:

    [pid 599] execve("/bin/sh", ["/bin/sh", "-c", "{ zoo lVCm \"/mnt/bbs/mystic/files/local/uploads/test.zoo\" >> \"/home/bbs/mystic/temp1/arcview.tmp\"; } > /dev/null 2>&1"], ["LANG=en_US.UTF-8", (cut)

    Tested viewing, (D)ownloading file from inside archive (including some "tricks" there which appear to be handled correctly now) and also downloading a compressed file list. All is working fine with all the archivers, and I could remove my trailing ">" from my "patched" command lines.

    Thanks again!

    Best regards
    Bj”rn

    --- Mystic BBS v1.12 A47 2021/08/05 (Linux/64)
    * Origin: Star Collision BBS, Uppsala, Sweden (2:201/137)
  • From Björn Wiberg@2:201/137 to g00r00 on Fri Aug 6 00:54:48 2021
    Hello again, g00r00!

    On 05 Aug 2021, Bj”rn Wiberg said the following...
    Tested viewing, (D)ownloading file from inside archive (including some "tricks"
    there which appear to be handled correctly now) and also downloading a

    The only "bad" thing I noticed is that the automatic "basenaming" (stripping path info from the entered filename) of "%2" for the Unpack Cmd can make it hard to perform archive member (file) selection for certain archivers.

    For instance, tar requires the "correct" (full) path of a file within an archive to be entered when selecting files for extraction.

    For example:

    $ tar tf ../test2.tar
    atest2.txt
    test1.txt
    subdir/
    subdir/btest2.txt
    subdir/test2.txt

    $ tar -xvf /tmp/test2.tar -C /tmp/bw2/ --xform='s,.*/,,' --overwrite -- "test2.txt"
    tar: test2.txt: Not found in archive
    tar: Exiting with failure status due to previous errors

    $ tar -xvf /tmp/test2.tar -C /tmp/bw2/ --xform='s,.*/,,' --overwrite -- "subdir/test2.txt"
    subdir/test2.txt

    One can enable wildcards, but it will be a "sloppy" match, selecting more than desired:

    $ tar -xvf /tmp/test2.tar -C /tmp/bw2/ --xform='s,.*/,,' --overwrite --wildcards -- "*test2.txt"
    atest2.txt
    subdir/btest2.txt
    subdir/test2.txt

    This will potentially leave a bunch of similarly named files from within the archive left over in the temp* directory, as only the file name entered will be deleted by Mystic...

    The --xform=... option does wonders, however, when it comes to junking paths for the extracted files (if one managed to extract any files). The result of the wildcard extraction above is:

    $ ls -1
    atest2.txt
    btest2.txt
    test2.txt

    The tar example with the sloppy match (so far) in Mystic is:

    Extension ³ TAR
    OS ³ Linux
    Description ³ GNU tar
    Pack Cmd ³ { cd "$(dirname "%2")" && tar -c -f "%1" -- $(basename "%2"); }
    Unpack Cmd ³ tar -x -f "%1" -C "%3" --xform='s,.*/,,' --overwrite --wildcards -- "*%2"
    View Cmd ³ { tar -t -f "%1" -v --full-time -- >> "%3%2"; }

    Best regards
    Bj”rn

    --- Mystic BBS v1.12 A47 2021/08/05 (Linux/64)
    * Origin: Star Collision BBS, Uppsala, Sweden (2:201/137)
  • From Björn Wiberg@2:201/137 to g00r00 on Fri Aug 6 14:35:14 2021
    Hello again, g00r00!

    On 06 Aug 2021, Bj”rn Wiberg said the following...
    The only "bad" thing I noticed is that the automatic "basenaming" (stripping path info from the entered filename) of "%2" for the Unpack Cmd can make it hard to perform archive member (file) selection for certain archivers.

    For instance, tar requires the "correct" (full) path of a file within an archive to be entered when selecting files for extraction.

    Apart from tar, this also applies to zip, lha and 7z (including LHA/LZH via 7-ZIP for Windows).

    (But not to arj e -e, zoo x:, or arc e which doesn't have any notion of subdirectories whatsoever).

    So it would be great if the %2 sanitization of Unpack Cmd would disallow things like ../ or ..\ but allow subdir/ and ./subdir and ./subdir/. and ././ and similar. Otherwise extraction of files from subdirectories becomes impossible.

    Best regards
    Bj”rn
    --- Mystic BBS v1.12 A47 2021/08/05 (Linux/64)
    * Origin: Star Collision BBS, Uppsala, Sweden (2:201/137)
  • From Björn Wiberg@2:201/137 to g00r00 on Fri Aug 6 15:00:02 2021
    Hello again, g00r00!

    On 06 Aug 2021, Bj”rn Wiberg said the following...
    For instance, tar requires the "correct" (full) path of a file within archive to be entered when selecting files for extraction.

    Apart from tar, this also applies to zip, lha and 7z (including LHA/LZH via 7-ZIP for Windows).

    (But not to arj e -e, zoo x:, or arc e which doesn't have any notion of subdirectories whatsoever).

    OK, a clarification might be in place:

    The problem is only with the sanitization of the file name that one can specify manually when choosing to (D)ownload (prompt #304) for an archiver which has no built-in archive browser in Mystic.

    So this does *not* affect archives which have built-in viewing support (ZIP, LHA/LZH and RAR), as the path passed in %2 to the Unpack Cmd in those cases *is* fully qualified.

    So, in practice, on a default installation, this only concerns 7z (and LHA via 7z on Windows).

    And any "picky" custom archivers one might have added after that, such as tar. :)

    Best regards
    Bj”rn
    --- Mystic BBS v1.12 A47 2021/08/05 (Linux/64)
    * Origin: Star Collision BBS, Uppsala, Sweden (2:201/137)
  • From Björn Wiberg@2:201/137 to g00r00 on Sun Aug 8 13:16:44 2021
    Hello g00r00!

    Just wanted to check if you managed to get https://sourceforge.net/projects/thegwolibrary/files/gwo-winxp/gwo0.11/gwo0.11-
    sample-win32.lzh/download (or other LHA files) to view correctly with the built-in archive viewer on your system?

    Best regards
    Bj”rn
    --- Mystic BBS v1.12 A47 2021/08/07 (Linux/64)
    * Origin: Star Collision BBS, Uppsala, Sweden (2:201/137)
  • From g00r00@1:129/215 to Björn Wiberg on Sun Aug 8 10:50:08 2021
    Just wanted to check if you managed to get https://sourceforge.net/projects/thegwolibrary/files/gwo-winxp/gwo0.11/gwo sample-win32.lzh/download (or other LHA files) to view correctly with the built-in archive viewer on your system?

    Yes I did.

    But it conflicts with my notes about how type 2 LZH represents filenames and directories. It seems like its a type 2 but it is representing directories
    like a type 1.

    In plain-speak I have enabled it so it will view correctly in Mystic but my concern is that it could actually break viewing in other type 2 LZH files.

    It'll be in today's build that I am about to upload. If you notice it breaks other archives let me know.

    ... A Meteor is an example of a rock star.

    --- Mystic BBS v1.12 A47 2021/08/07 (Windows/64)
    * Origin: Sector 7 * Mystic WHQ (1:129/215)