I just did some tests, and managed to successfully import a 4.45 mb binkd.log into a Squish area using MsgEd. I could browse to the last line Ok. But MaxED (the Maximus editor) could only display 623 lines (or ~37,466 bytes) of that message.
I attempted to upload the file via the Msg_Upload menu option using mTelnet Zmodem and it cut off at 144 lines with,
=============================
Saving your message
Message too long -- Truncated.
(#6).
=============================
Exporting the saved message to disk reveals the 144 line message is about 8,122
- 8,384 bytes (I did two upload tests):
===============================================
15/02/08 08:45 8,384 test1.txt
15/02/08 09:22 8,122 test2.txt ===============================================
And when doing a mTelnet ASCII upload inside MaxEd, it looked like it uploads the text line-by-line properly until about the 250th line when it starts truncating the MaxEd display. (250 lines of my Binkd.log was 14,774 bytes). The
Windows NT virtual memory usage went through the roof, and eventually crashed the taskmanager, the mouse froze and I had to cold boot. Heh. This may have been a Maximus/NetFoss NTVDM or mTelnet problem. Who knows.
+---------+
| Results |
+---------+
It looks like Squish can handle more than 4.5 mb messages. But I don't know the
theoretical message size limit. 4.5 mbs is good enough for me.
And most of the limits seen so far are due to Maximus. Somebody needs to up the
int types to floating doubles in the Maximus source.
Apparently if you want to post a large message, import it using an editor other
than MaxEd or Maximus functions (which seems to only be able to view 35'ish kbs
of the whole message and/or accept 8 kb - 14 (maybe 16) kb uploads).
+------------+
| Conclusion |
+------------+
Inconclusive. But,
Maximum number of file/message areas Unlimited
Maximum number of message per area 65535
Maximum EchoMail message size 8-32k (?)
Maximum number of lines in messages 250
Maximum number of network addresses 16
Maximum number of nodes you can scan to Unknown
Maximum length of echomail area tag Unknown
Here's the thread from RA_SUPPORT:
* Forwarded from RA_SUPPORT by Minh Van Le (3:712/104@fidonet).
* Originally by: Minh Van Le (3:712/104@fidonet), 15-Feb'08 06:27.
* Originally to: Scott Little (3:712/848).
---------- Forwarded message Begin ----------
@MSGID: 3:712/104@fidonet 47b53945
@REPLY: 3:712/848 47b43be6
Hello Scott !
On 14-Feb'08 23:52, Scott Little wrote to Minh Van Le:
Yes. Most (all?) tossers allow you to specify the full
path and filename for each area.
I keep mine in lettered subdirectories (\fido\a\a*,
\fido\b\b*, etc).
Out of curiosity, what are those denoting ? a, b, c, etc. fido echo names ?
There are probably old DOS based repair tools. I haven't
had a corrupt message base since I stopped using DOS so it
hasn't been an issue. I still keep full archives of
Maybe you needed to up your SHARE.EXE= :) ...
everything though (all incoming mail files are backed up as
they are, the message bases are backed up before and after
nightly maintenance and I have the mail tosser send a copy
of everything passing through to a local point address).
I just backup incoming mail :) And full m:\bbs backups after a while.
I got 18 mbs in my message base :)
=================================================
Subj : dir /s m:\base\MSGBASE report
Attr : Pvt Loc
───3:712/104@fidonet────────── 2008-02-15 07:42:32
Total Files Listed:
923 File(s) 18,754,826 bytes
657,117,184 bytes free
-+- MakeMsg v2.31
+ Origin: mmbatch.bat
=================================================
How long is your redundancy ?
However.. Squish is probably the better of the two, should
it become damaged. Since it only has one real data file,
the rest can be regenerated from that. JAM keeps the
message text and metadata in two separate files so if they
get out of sync, you're hosed.
Woohoo ! score for Squish. I knew Squish was better.
In Maximus the Squish areas have a maximum message limit of
65535. But I'm not sure if this is a limitation of Squish,
Maximus or editor. Would be handy to know.
Looks to be a Maximus limit. The Squish library used in
EleBBS (MkMsg) uses a signed 32bit integer for message
numbers (ie. 2^31-1, over 2 billion).
That's handy to know.
Why would it be signed. Are message numbers meant to go backwards ?
You wouldn't happen to know the maximum message size ?
In my tests, MakeMsg failes to import more than ~86 kbs. Not sure if this was a
limitation of MakeMsg, which seems to be a 16 bit DOS app. The other tool I got
is MPost but that has a hardcoded limit of 8 kb unless I recompile from source with the necessary changes.
... ... I just imported a 4.45 mb binkd.log into a Squish area using MsgEd without any probs. I can read to the last line.
But MaxED (the Maximus editor) fails after displaying 623 lines (or 37,466 bytes): ============================================================================ = ...
...
...
[619] 30 Sep 06:29:42 [183] started client #1, id=248
[620] 30 Sep 06:29:42 [224] created M:\mailing\mailer\bt\out\ftn\02c80000.cs y [621]+ 30 Sep 06:29:42 [224] call to 3:712/0@fidonet
[622] 30 Sep 06:29:42 [224] resolving `sysgod.org'...
[623] 30 Sep 06:29:42 [224] trying 218.214.9.232...
C:\tmp>dir test.txt
Volume in drive C is Local Disk
Volume Serial Number is 90D6-6C28
Directory of C:\tmp
15/02/2008 07:24a 37,466 test.txt
1 File(s) 37,466 bytes
0 Dir(s) 7,014,924,288 bytes free ============================================================================ =
So it looks like Squish can handle more than 4.5 mb messages. But I don't know the theoretical limit.
I need to up the int's to floating doubles somewhere in the Maximus source.
I'm also unsure what the maximum number of areas is for
Squish.
In the Squish tosser documentation it says the maximum
number of areas is limited to memory. So this could be
virtually unlimited areas, if using disk swapping.
Pretty much. Since each area is its own set of files, any
area limits are in the software not the format.
There're also theoretical file system limits, but these are practically irrelevant. According to wikipedia the maximum files on NTFS is 4 trillion, and
something about VolumeSize / 2^12 inodes for EXT3. EXT2 has a 1.3 x 10^20 per directory.
-+- Msged/386 4.30
+ Origin: ypan.dyndns.org loves Msged... (3:712/104)
---------- Forwarded message End ----------
--- Msged/386 4.30
* Origin: ypan.dyndns.org loves Msged... (3:712/104)