From Newsgroup: alt.windows7.general
On Tue, 2/10/2026 12:03 AM, Kenny McCormack wrote:
In article <jb4lokd9i75r8hud0vvcau702llheeojr4@4ax.com>,
Char Jackson <none@none.invalid> wrote:
...
Taking a casual look just now, the biggest *single* post that I see is
2,796,888,255 KB, (about 2.8 TB!), so yeah, size limits aren't a real
thing.
Really? Someone posted an almost 3TB post on Usenet? What was it?
(not looking for a link to the post or anything like that, just curious
what it was - what could be that big?)
Large objects are broken up into individual messages small enough
that some transport guarantee between servers is not broken.
Maybe the Subject of the message says "0001 of 9999 messages".
We'll see in a moment, whether the server filter rejects my post
while this content is present. Normally, this material would be a
trigger for rejection (a binary attempt in a text group).
=ybegin part=1 line=128 size=87058 name=some.file
=ypart begin=1 end=87058
=yend size=87058 part=1 pcrc32=d25faabf
Lines in USENET usually have a "physical limit" of around 1000 characters. However, by the usage of the USENET line continuation character, it is
possible to make "virtual" lines which are a lot longer. A poster here,
as a demo, once sent "a million digits of PI" as a message whose
header indicated "there was just one line in the file", and that trick
was achieved via line continuation.
USENET messages have a finite size, so you must chop images up into pieces
for transmitting anything large. When using large objects such as 7GB
movies, you use PAR2 and "transmit PAR blocks", which appear just like
other messages in your series. For example, if I had "0001 of 9999 messages" perhaps the payload is only 8000 messages plus 1999 PAR blocks. The
PAR software can then "compensate" for deleted messages (the movie
people have a BOT which attempts to delete material, which is
why lots of PAR blocks are needed). It does not matter whether PAR
blocks or movie blocks are deleted, as long as the 8000 messages
arrive (8000 or more messages for this movie), the PAR software
can recover them and make a solid file of appropriate size from the
result.
It is claimed (by one binaries poster), that he uploads the same set
of movies (7GB each) every day, as a total of 1TB of chopped-messages. Naturally, this takes not only a decent ISP connection, it also
takes the highest account possible on an all-you-can-eat USENET
binary server (open twenty connections in parallel kind of thing
as the USENET server is weak on speeds). Such a transmission would
need PAR blocks, but because virtually the entire transmission could
be erased by his opponents... he just sends the whole shitload the
very next day.
Binary servers claiming "good retention", have to absorb this load.
Someone has to walk down to the server room and plug in another
1TB drive :-) But when the materials are deleted, they might handle
the deletions properly. It's only if that poster had automated
this and wasn't watching, that retaining 1TB sets from one day to the
next, could have an impact on the server. But based on the amount the
person pays per month to do this, the server operator has figured
out what the retention cost is on average and taken this into account.
The normal mechanism for cataloging and fetching this stuff, has
been altered. One server may not have the metadata on board, with the
intention being to prevent the deletion war. Then the metadata is held
on some other server, the users then collect the metadata and use
it on their toolage, to fetch the (undeletable) messages. This is the
kind of stuff that goes on as you sleep.
I just pick this stuff up, in passing. Like from a Reddit or the like.
I'm not interested in Hollywood movies particularly. I haven't turned
on a TV set here, in some years. The last time I watched "prime time TV",
and looked at the plot, my conclusion was "some stoner wrote this", the
plot was that bad. That's prime time for you. Imagine what "The View"
must be like at 10AM in the morning <shudder>.
If your USENET client does not have the toolage for the handling of
segmented binary payloads, then reassembly by hand is a bore. Even relatively small collections of messages, have missing ones, and unless the person
uses PAR, many times you may find a message or two is missing which you
might need to make the solid file. 1,2,5,6,7 <dammit>.
The howardknight server was ruined, when some clever person figured out
they could upload movies and then "howard would be their server" and
serve messages (under automation) to the audience. The admin at howard
added code to truncate long messages (regardless of content!), which is
why after that time, you could not rely on howard for literal copies of
what was said on USENET. And howard is down now, and likely "for the count".
I don't think anyone will fix it now. The prompt here, still works, but the backend is broken.
https://al.howardknight.net/
Paul
--- Synchronet 3.21b-Linux NewsLink 1.2