• children ansi pack...

    From Shurato@21:2/148 to All on Wed Feb 28 19:01:00 2024
    Was ignored by allfix because it had more than 8 characters in the title and it's a dos program.

    ---
    Shurato, Sysop Shurato's Heavenly Sphere (ssh, telnet, pop3, ftp,nntp)
    (ports 22, 23, 110, 21, 119) (ssh: login bbs password shsbbs)


    *** THE READER V4.50 [freeware]
    ---
    * Origin: Shurato's Heavenly Sphere telnet://shsbbs.net (21:2/148)
  • From Avon@21:1/101 to Shurato on Thu Feb 29 15:18:43 2024

    On 28 Feb 2024 at 07:01p, Shurato pondered and said...

    Was ignored by allfix because it had more than 8 characters in the title and it's a dos program.

    OK, just know I hatch them as they are named, so importing some may require more manual intervention on your part should you wish to include them.

    I will be hatching more ANSI art packs in the coming days.

    Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

    --- Mystic BBS v1.12 A48 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From Andrew Leary@21:4/105 to Avon on Fri Mar 1 00:45:11 2024
    Hello Avon!

    29 Feb 24 15:18, you wrote to Shurato:

    OK, just know I hatch them as they are named, so importing some may require more manual intervention on your part should you wish to
    include them.

    My recommendation is that you store the entire archive inside a .ZIP file with an 8.3 DOS compatible filename. This will allow the file to be distributed without manual intervention, and the destination nodes can unzip it to recover the original archive.

    I will be hatching more ANSI art packs in the coming days.

    Great!

    Andrew

    --- GoldED+/LNX 1.1.5-b20240209
    * Origin: Phoenix BBS * phoenix.bnbbbs.net (21:4/105)
  • From Shurato@21:2/148 to Andrew Leary on Fri Mar 1 16:06:00 2024

    Hello Avon!

    29 Feb 24 15:18, you wrote to Shurato:

    OK, just know I hatch them as they are named, so importing some may require more manual intervention on your part should you wish to include them.

    My recommendation is that you store the entire archive inside a .ZIP file with an 8.3 DOS compatible filename. This will allow the file to be distributed without manual intervention, and the destination
    nodes can unzip it to recover the original archive.

    I will be hatching more ANSI art packs in the coming days.

    Great!

    Yeah, it was pkunzip and pkzip that were restricted to 8.3, not irex or
    allfix. It needed to be unzipped to get the file_id.diz info and lost the
    long filename, then allfix couldn't find it any more.

    ---
    Shurato, Sysop Shurato's Heavenly Sphere (ssh, telnet, pop3, ftp,nntp)
    (ports 22, 23, 110, 21, 119) (ssh: login bbs password shsbbs)


    *** THE READER V4.50 [freeware]
    ---
    * Origin: Shurato's Heavenly Sphere telnet://shsbbs.net (21:2/148)
  • From Avon@21:1/101 to Andrew Leary on Sat Mar 2 20:03:56 2024
    On 01 Mar 2024 at 12:45a, Andrew Leary pondered and said...

    My recommendation is that you store the entire archive inside a .ZIP
    file with an 8.3 DOS compatible filename. This will allow the file to
    be distributed without manual intervention, and the destination nodes
    can unzip it to recover the original archive.

    while I appreciate the reasons for this request I'm time poor to do so, and am just working to hatch the releases using the filenames that have been assigned the compressed archives by the authors.

    It gives me an idea for a mod request.

    Kerr Avon [Blake's 7] 'I'm not expendable, I'm not stupid and I'm not going' avon[at]bbs.nz | bbs.nz | fsxnet.nz

    --- Mystic BBS v1.12 A48 (Linux/64)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)
  • From deon@21:2/116 to All on Sun Mar 3 09:56:07 2024
    Re: children ansi pack...
    By: Andrew Leary to Avon on Fri Mar 01 2024 12:45 am

    Howdy,

    OK, just know I hatch them as they are named, so importing some may require more manual intervention on your part should you wish to include them.

    My recommendation is that you store the entire archive inside a .ZIP file with an 8.3 DOS compatible filename. This will allow the file to be distributed without manual intervention, and the destination nodes can unzip it to recover the original archive.

    One of the things I've thought about implementing for clrghouz would be a "force 8.3" like setting - so that long file names are sent downstream in 8.3 format (to those nodes that select it).

    IE: While clrghouz might receive "realy_long_filename.zipped" and store it that way internally, it could send it to you as "somename.zip".

    The devel is in the detail - sometimes filenames are descriptive so arbitrarly choping of anything before a dot to 8 chars and anything after a dot to 3 chars could loose the name.

    And by doing above, its likely that you could clobber (or the downstream node think it has) the file already - especially if two files clobber to the same 8.3 name. (I used to have a similiar problem with MBSE a couple of years ago - where the received name is changed by the receiver and out of sync with the TIC).

    I could rename it to a unique name to clrghouz (a mash of filearea id and file id) - but when folks talk about (for example) the mystic files, you wouldnt know what was what if you were looking through your file listing (especially outside of the BBS).

    Any ideas on smart ways of handling this?


    ...
    --- SBBSecho 3.20-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)
  • From AKAcastor@21:1/162 to Deon on Sat Mar 2 15:43:04 2024
    One of the things I've thought about implementing for
    clrghouz would be a "force 8.3" like setting - so that
    long file names are sent downstream in 8.3 format (to
    those nodes that select it).

    As a sysop running DOS software, a force 8.3 setting does sound useful to me.

    IE: While clrghouz might receive
    "realy_long_filename.zipped" and store it that way
    internally, it could send it to you as "somename.zip".

    A suggestion - if there is FILE_ID.DIZ/FILE_ID.ANS inside really_long_filename.zip then that could be placed inside somename.zip also, to make it easy for tools to still find the description files.

    The devel is in the detail - sometimes filenames are
    descriptive so arbitrarly choping of anything before a
    dot to 8 chars and anything after a dot to 3 chars could
    loose the name.

    You're right about the details being tricky. I don't have any great insight here, but I do think you are doing well considering potential drawbacks.

    If the 'replaces' keyword is used in the TIC file, would it be better to modify that to an 8.3 filename as well, or would it be left as-is?


    Chris/akacastor

    --- Maximus 3.01
    * Origin: Another Millennium - Canada - another.tel (21:1/162)
  • From Andrew Leary@21:4/105 to deon on Sun Mar 3 00:06:18 2024
    Hello deon!

    03 Mar 24 09:56, you wrote to all:

    My recommendation is that you store the entire archive inside a
    .ZIP file with an 8.3 DOS compatible filename. This will allow the
    file to be distributed without manual intervention, and the
    destination nodes can unzip it to recover the original archive.

    One of the things I've thought about implementing for clrghouz would
    be a "force 8.3" like setting - so that long file names are sent downstream in 8.3 format (to those nodes that select it).

    IE: While clrghouz might receive "realy_long_filename.zipped" and
    store it that way internally, it could send it to you as
    "somename.zip".

    The devel is in the detail - sometimes filenames are descriptive so arbitrarly choping of anything before a dot to 8 chars and anything
    after a dot to 3 chars could loose the name.

    And by doing above, its likely that you could clobber (or the
    downstream node think it has) the file already - especially if two
    files clobber to the same 8.3 name. (I used to have a similiar problem with MBSE a couple of years ago - where the received name is changed
    by the receiver and out of sync with the TIC).

    I could rename it to a unique name to clrghouz (a mash of filearea id
    and file id) - but when folks talk about (for example) the mystic
    files, you wouldnt know what was what if you were looking through your file listing (especially outside of the BBS).

    Any ideas on smart ways of handling this?

    There is no easy way to do it in an automated fashion. What MBSE does and you're proposing to add to ClrgHouz are an attempt, but manual sysop intervention by storing the original archive plus a file_id.diz in an 8.3 named archive is by far the best chance for success.

    Andrew

    --- GoldED+/LNX 1.1.5-b20240209
    * Origin: Phoenix BBS * phoenix.bnbbbs.net (21:4/105)
  • From Andrew Leary@21:4/105 to AKAcastor on Sun Mar 3 00:11:16 2024
    Hello AKAcastor!

    02 Mar 24 15:43, you wrote to Deon:

    As a sysop running DOS software, a force 8.3 setting does sound useful
    to me.

    IE: While clrghouz might receive
    "realy_long_filename.zipped" and store it that way
    internally, it could send it to you as "somename.zip".

    A suggestion - if there is FILE_ID.DIZ/FILE_ID.ANS inside really_long_filename.zip then that could be placed inside somename.zip also, to make it easy for tools to still find the description files.

    I suggested the same thing.

    The devel is in the detail - sometimes filenames are
    descriptive so arbitrarly choping of anything before a
    dot to 8 chars and anything after a dot to 3 chars could
    loose the name.

    You're right about the details being tricky. I don't have any great insight here, but I do think you are doing well considering potential drawbacks.

    We try to think about these things sometimes... lol

    If the 'replaces' keyword is used in the TIC file, would it be better
    to modify that to an 8.3 filename as well, or would it be left as-is?

    However the file was distributed originally is what the Replaces keyword needs to list. If the original archive and file_id.diz are stored inside an 8.3 archive before hatching, then this is easy. If they are renamed or repacked enroute, it will likely require manual intervention to handle replacing the older file.

    Andrew

    --- GoldED+/LNX 1.1.5-b20240209
    * Origin: Phoenix BBS * phoenix.bnbbbs.net (21:4/105)
  • From deon@21:2/116 to AKAcastor on Sun Mar 3 17:24:27 2024
    Re: Filename conversion (was children ansi pack)
    By: AKAcastor to Deon on Sat Mar 02 2024 03:43 pm

    As a sysop running DOS software, a force 8.3 setting does sound useful to me.

    IE: While clrghouz might receive
    "realy_long_filename.zipped" and store it that way
    internally, it could send it to you as "somename.zip".

    A suggestion - if there is FILE_ID.DIZ/FILE_ID.ANS inside really_long_filename.zip then that could be placed inside somename.zip also, to make it easy for tools to still find the description files.

    Actually, I wasnt suggesting puting "realy_long_filename.zipped" into another (8.3) zip file - I was suggesting giving it to the downstream system as "somename.zip" - thus if there was a FILE_ID* in it, it would be accessible as is.

    (What does DOS do when you unzip "realy_long_filename.extension" inside a zip file - I dont recall - it truncates it right...?)

    If the 'replaces' keyword is used in the TIC file, would it be better to modify that to an 8.3 filename as well, or would it be left as-is?

    I could do that - as clrghouz dynamically creates the TIC file when sending files downstream. However, I have doubts that that is a good idea as well.. (It would be a shame if the replaces and thus the clobbering of the original file name resolved to a file that you didnt want to have deleted.)

    Hmm....


    ...
    --- SBBSecho 3.20-Linux
    * Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)
  • From AKAcastor@21:1/162 to Deon on Sat Mar 2 22:47:44 2024
    Actually, I wasnt suggesting puting
    "realy_long_filename.zipped" into another (8.3) zip file
    - I was suggesting giving it to the downstream system as
    "somename.zip" - thus if there was a FILE_ID* in it, it
    would be accessible as is.

    Oh OK, I misunderstood, I was thinking to embed the original zipfile inside another, and letting the end user deal with the consequences.

    (What does DOS do when you unzip
    "realy_long_filename.extension" inside a zip file - I
    dont recall - it truncates it right...?)

    Yes, pkunzip truncates the filename and extension. If there is a period in the filename in addition to the extension then pkunzip fails.


    Tested with PKUNZIP 2.04g in MS-DOS 6.22 in DOSBox-X - file REALLY01.ZIP contains really_long_filename.zip which contains really_long_text_filename.andstuff.txt:

    C:\DOWNLOAD\T>pkunzip really01.zip

    PKUNZIP (R) FAST! Extract Utility Version 2.04g 02-01-93
    Copr. 1989-1993 PKWARE Inc. All Rights Reserved. Shareware Version
    PKUNZIP Reg. U.S. Pat. and Tm. Off.

    80486 CPU detected.
    EMS version 4.00 detected.
    XMS version 3.00 detected.
    DPMI version 0.90 detected.

    Searching ZIP: REALLY01.ZIP
    Extracting: really_long_filename.zip

    C:\DOWNLOAD\T>dir

    Volume in drive C is MS-DOS_6
    Volume Serial Number is 582C-AB6D
    Directory of C:\DOWNLOAD\T

    . <DIR> 03-02-24 10:45p
    .. <DIR> 03-02-24 10:45p
    REALLY01 ZIP 438 03-02-24 10:45p
    REALLY_L ZIP 240 03-02-24 10:44p
    4 file(s) 678 bytes
    45,826,048 bytes free

    C:\DOWNLOAD\T>pkunzip really_l.zip

    PKUNZIP (R) FAST! Extract Utility Version 2.04g 02-01-93
    Copr. 1989-1993 PKWARE Inc. All Rights Reserved. Shareware Version
    PKUNZIP Reg. U.S. Pat. and Tm. Off.

    80486 CPU detected.
    EMS version 4.00 detected.
    XMS version 3.00 detected.
    DPMI version 0.90 detected.

    Searching ZIP: REALLY_L.ZIP
    PKUNZIP: (W10) Warning! can't create: really_long_text_filename.andstuff.txt

    PKUNZIP: (E11) No file(s) found.

    C:\DOWNLOAD\T>

    If the 'replaces' keyword is used in the TIC file, would it be better to modify that to an 8.3 filename as well, or would it be left as-is?

    I could do that - as clrghouz dynamically creates the
    TIC file when sending files downstream. However, I have
    doubts that that is a good idea as well.. (It would be a
    shame if the replaces and thus the clobbering of the
    original file name resolved to a file that you didnt
    want to have deleted.)

    Yeah leaving the filename intact for the 'replaces' keyword probably does make the most sense and is the safest, asn Andrew also mentioned.


    Chris/akacastor

    --- Maximus 3.01
    * Origin: Another Millennium - Canada - another.tel (21:1/162)