Hi Everyone,
I've connected Michael Dukelsky to this echo today.
Michael sends out the R50 file echos.
I've connected Michael Dukelsky to this echo today.
Michael sends out the R50 file echos.
Sure hope he does NOT distribute LFN files!
I've connected Michael Dukelsky to this echo today.
Michael sends out the R50 file echos.
Sure hope he does NOT distribute LFN files!
Hi Bob,
I've connected Michael Dukelsky to this echo today.
Michael sends out the R50 file echos.
Sure hope he does NOT distribute LFN files!
I spoke to his source for those files, and he is now aware of the
problems his last hatched caused. He's going to rename his archives,
etc.
On 2017 Aug 28 22:57:00, you wrote to Janis Kracht:
I've connected Michael Dukelsky to this echo today.
Michael sends out the R50 file echos.
Sure hope he does NOT distribute LFN files!
yeah, i've got three over here received on 25 Aug 2017...
fidoosxip.tar.bz2
fido_mac_ppc.zip
gposx-115-20170303.zip
their TIC files are gone with "file not found" errors because they are
not 8.3 and the code simply can't see them... the log records the file
names from the TICs chopped at 12 characters long... so no wonder they
can't be found...
I've connected Michael Dukelsky to this echo today.
Michael sends out the R50 file echos.
Welcome Michael :)
I've connected Michael Dukelsky to this echo today.Sure hope he does NOT distribute LFN files!
Michael sends out the R50 file echos.
Hello Bob,
Monday August 28 2017, Bob Seaborn wrote to Janis Kracht:
I've connected Michael Dukelsky to this echo today.Sure hope he does NOT distribute LFN files!
Michael sends out the R50 file echos.
No, I never hatch files with long file names, but I cannot prevent
others from doing it, I can only ask not to do it.
Monday August 28 2017, Bob Seaborn wrote to Janis Kracht:
I've connected Michael Dukelsky to this echo today.Sure hope he does NOT distribute LFN files!
Michael sends out the R50 file echos.
No, I never hatch files with long file names, but I cannot prevent
others from doing it, I can only ask not to do it.
I believe the way things work, is that others send you the files, and you send >them on to the Filegate System. Should someone send you a file with a LFN, >why don't you simply pack it into an 8.3 archive, with a note inside that >explains hat it's a LFN file? To my thinking, that should be the simplest >method of ensuring the Filegate only gets 8.3 files, yes? Then you send the >originator note that advises them that LFN's are strongly discouraged.
yeah, i've got three over here received on 25 Aug 2017...
fidoosxip.tar.bz2
fido_mac_ppc.zip
gposx-115-20170303.zip
their TIC files are gone with "file not found" errors because they are not 8.3
and the code simply can't see them... the log records the file names from the TICs chopped at 12 characters long... so no wonder they can't be found...
I believe the way things work, is that others send you the files, and
you send them on to the Filegate System. Should someone send you a
file with a LFN, why don't you simply pack it into an 8.3 archive,
with a note inside that explains that it's a LFN file?
Hello Bob,
Monday August 28 2017, Bob Seaborn wrote to Janis Kracht:
I've connected Michael Dukelsky to this echo today.
Michael sends out the R50 file echos.
Sure hope he does NOT distribute LFN files!
No, I never hatch files with long file names, but I cannot prevent
others from doing it, I can only ask not to do it.
BBBS just passed the files right through (there is no way to tell it
to stop LFN files and it knows what tar.bz or tar.bz2 files are), so
I've been working with the fellow who sent Michael Dukelsky these
files.
I've connected Michael Dukelsky to this echo today.
Michael sends out the R50 file echos.
Sure hope he does NOT distribute LFN files!
No, I never hatch files with long file names, but I cannot prevent
others from doing it, I can only ask not to do it.
Tell him to contact me as my system does play with long fn and will convert them for legacy systems.
... we have already agreed the following naming
scheme:
File names are of the type NBOymmdd.zip where
N is the first letter of the program Name being sent: B - binkd, H - husky, G
Golded.
B is the program development Branch: C - current, T - stable, P - current with
Perl, L - stable with Perl, S - sources.
O is the Operating system: W - Windows, L - Linux, M - Mac, F - FreeBSD.
Five decimal digits that follow these three letters denote the program version
date.
y is the last digit of the year,
mm is the month number from 01 to 12,
dd is the day number from 01 to 31.
Thank you for offering help, but we have already agreed the following naming scheme:husky,
File names are of the type NBOymmdd.zip where
N is the first letter of the program Name being sent: B - binkd, H -
G - Golded. B is the program development Branch: C - current, T - stable,P
- current with Perl, L - stable with Perl, S - sources. O is the Operating system: W - Windows, L - Linux, M - Mac, F - FreeBSD. Five decimal digits that follow these three letters denote the program version date. y is the last digit of the year, mm is the month number from 01 to 12, dd is theday
number from 01 to 31.
Thank you for offering help, but we have already agreed the
following naming scheme:
File names are of the type NBOymmdd.zip where
N is the first letter of the program Name being sent: B - binkd,
H - husky, G - Golded. B is the program development Branch: C -
current, T - stable, P - current with Perl, L - stable with Perl,
S - sources. O is the Operating
system: W - Windows, L - Linux, M - Mac, F - FreeBSD. Five
decimal digits that follow these three letters denote the program
version date. y is the last digit of the year, mm is the month
number from 01 to 12, dd is the day number from 01 to 31.
How do you differentiate between binkd 0.9, 1.0 and 1.1 version
releases?
Sysop: | DaiTengu |
---|---|
Location: | Appleton, WI |
Users: | 906 |
Nodes: | 10 (0 / 10) |
Uptime: | 211:32:49 |
Calls: | 12,035 |
Files: | 186,477 |
Messages: | 2,214,445 |