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.
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!
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.
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.
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?
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?
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.
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?
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.)
| Sysop: | Immortal |
|---|---|
| Location: | Spanish Fork, UT |
| Users: | 15 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 04:59:46 |
| Calls: | 514 |
| Files: | 3,435 |
| Messages: | 99,387 |