Subj : Filename conversion (was children ansi pack)
To   : deon
From : Andrew Leary
Date : Sun Mar 03 2024 12:06 am

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.

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

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

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

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

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

 de> 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)

.