I rebuilt Mystic from scratch a couple of days ago, but I'm not seeing any files incoming. I imported and configured all the fsxNet file bases, but
maybe I've missed something? My Mystic BBS Software base, for example, is set up as follows:

Base Name: Mystic BBS Software
Echo Tag: FSX_MYST
Net Address: 21:4/123 (fsxnet)
Export To: 1 node(s) [fsxNet Niba HUB 21:4/100]
List ACS ACS: s10z1
etc.

+=====================+-+=======+----------------------------------------
| *H:U:M:O:N:G:O:U:S* | | B:B:S | nathanael : jenandcal.familyds.org:2323 +=====================+-+=======+----------------------------------------

--- Mystic BBS v1.12 A41 2018/12/27 (Raspberry Pi/32)
* Origin: *HUMONGOUS* BBS (21:4/123)

I rebuilt Mystic from scratch a couple of days ago, but I'm not seeing any files incoming. I imported and configured all the fsxNet file bases, but maybe I've missed something? My Mystic BBS Software base, for example, is se up as follows:

Base Name: Mystic BBS Software
Echo Tag: FSX_MYST
Net Address: 21:4/123 (fsxnet)
Export To: 1 node(s) [fsxNet Niba HUB 21:4/100]
List ACS ACS: s10z1

If you just reset everything from scratch, then you probably won't get
any new files in this base until at least one is hatched into it. Or is
it something else?

--- Platinum Xpress/Win/WINServer v3.1
* Origin: fsxNet: Omicron Theta * Southaven, MS * winserver.org (21:2/136)

On 26 Jan 2019, nathanael said the following...

I rebuilt Mystic from scratch a couple of days ago, but I'm not seeing
any files incoming. I imported and configured all the fsxNet file bases,

Did you receive the files that came through about 11 hours ago? It was the
new nodelist for fsxNet.

I just checked the logs on the hub 4 system, and it looks like they're being sent to your system.

Take a look in your mis.log file and see if they were received, and also your mutil.log file, to see what happened to them during mail processing.

Export To: 1 node(s) [fsxNet Niba HUB 21:4/100]

You may want to take this out of your setup. What Mystic will do, is whenever
a new file comes into the area, it will be exported back to the hub. It
should get flagged as a duplicate file, but there's no need to have unneeded transfers. :)


---

Black Panther(RCS)
a.k.a. Dan Richter
Sysop - Castle Rock BBS
telnet://bbs.castlerockbbs.com
http://www.castlerockbbs.com
The sparrows are flying again....

--- Mystic BBS v1.12 A42 2018/12/30 (Linux/64)
* Origin: Castle Rock BBS - bbs.castlerockbbs.com (21:1/186)

Take a look in your mis.log file and see if they were received, and also your mutil.log file, to see what happened to them during mail processing.

They were stuck in echomail/in/ and my mutil log showed:

----------------- MUTIL v1.12 A41 2018/12/27 Sun, Jan 27 2019 (loglevel 3)
+ Jan 27 03:42:11 Startup using mailin.ini
- Jan 27 03:42:11 EXEC ImportEchoMail
- Jan 27 03:42:11 EXEC FileToss
+ Jan 27 03:42:11 Process: Toss FDN/TIC Files
+ Jan 27 03:42:12 Results: Bad dir does not exist /mystic/files/badfile/ in 0.02s
! Jan 27 03:42:12 Status: FATAL
+ Jan 27 03:42:12 Process: Importing EchoMail
+ Jan 27 03:42:12 Waiting for BUSY nodes
- Jan 27 03:42:12 LINKS:
- Jan 27 03:42:12 Node 1 21:4/100@fsxnet
! Jan 27 03:42:12 Import from /mystic/echomail/in/
! Jan 27 03:42:12 Unknown inbound file GDYNSRC.tic
! Jan 27 03:42:12 Unknown inbound file GDYNSRC.ZIP
! Jan 27 03:42:12 Unknown inbound file GDYNWIN.tic
! Jan 27 03:42:12 Unknown inbound file GDYNWIN.ZIP
! Jan 27 03:42:12 Unknown inbound file FSXNET.Z32
! Jan 27 03:42:12 Unknown inbound file FSXNET.tic
! Jan 27 03:42:12 Unknown inbound file fsxinfo.tic
! Jan 27 03:42:12 Unknown inbound file fsxinfo.zip
+ Jan 27 03:42:12 Extracting 0000ffe9.sai
- Jan 27 03:42:12 unzip -oqqjC "/mystic/echomail/in/0000ffe9.sai" "*.pkt"
-d /mystic/temputil/
+ Jan 27 03:42:12 Importing 0fc4eed8.pkt (21:4/100 to 21:4/123)
+ Jan 27 03:42:12 Import #1688 to FSX_BOT
! Jan 27 03:42:12 Import from /mystic/echomail/in/unsecure/.

So I created /mystic/files/badfile/ and the next mail toss tossed them there. Hmm.

You may want to take this out of your setup. What Mystic will do, is

Done. However, I tried initially to do this globally via Export Kill. Am I
not understanding what Export Kill is for?

+=====================+-+=======+----------------------------------------
| *H:U:M:O:N:G:O:U:S* | | B:B:S | nathanael : jenandcal.familyds.org:2323 +=====================+-+=======+----------------------------------------

--- Mystic BBS v1.12 A41 2018/12/27 (Raspberry Pi/32)
* Origin: *HUMONGOUS* BBS (21:4/123)

any new files in this base until at least one is hatched into it.

I know file traffic is light, so I waited a couple of days before asking. But it appears they're arriving, just not getting tossed properly. I must be missing a setting somewhere.

+=====================+-+=======+----------------------------------------
| *H:U:M:O:N:G:O:U:S* | | B:B:S | nathanael : jenandcal.familyds.org:2323 +=====================+-+=======+----------------------------------------

--- Mystic BBS v1.12 A41 2018/12/27 (Raspberry Pi/32)
* Origin: *HUMONGOUS* BBS (21:4/123)

So I created /mystic/files/badfile/ and the next mail toss tossed them there. Hmm.

Spoke too quickly. Looks like two of the files (GDYNSRC.ZIP and GDYNWIN.ZIP) were tossed correctly, while fsxinfo.* and FSXNET.* ended up in badfile/.

My eyes don't seen any config differences in the configurations of FSX_DOOR
and FSX_INFO, and the files/fsx_info/ dir exists.

+=====================+-+=======+----------------------------------------
| *H:U:M:O:N:G:O:U:S* | | B:B:S | nathanael : jenandcal.familyds.org:2323 +=====================+-+=======+----------------------------------------

--- Mystic BBS v1.12 A41 2018/12/27 (Raspberry Pi/32)
* Origin: *HUMONGOUS* BBS (21:4/123)

On 27 Jan 2019, nathanael said the following...

So I created /mystic/files/badfile/ and the next mail toss tossed them there. Hmm.

I had forgotten about that. I had the same issue when I switched over to Linux...

Done. However, I tried initially to do this globally via Export Kill. Am
I not understanding what Export Kill is for?

That's what it should be for. I usually go the the 'Echomail Nodes' and hit '/F' and select the file areas for that node.


---

Black Panther(RCS)
a.k.a. Dan Richter
Sysop - Castle Rock BBS
telnet://bbs.castlerockbbs.com
http://www.castlerockbbs.com
The sparrows are flying again....

--- Mystic BBS v1.12 A42 2018/12/30 (Linux/64)
* Origin: Castle Rock BBS - bbs.castlerockbbs.com (21:1/186)

On 27 Jan 2019, nathanael said the following...

Spoke too quickly. Looks like two of the files (GDYNSRC.ZIP and GDYNWIN.ZIP) were tossed correctly, while fsxinfo.* and FSXNET.* ended
up in badfile/.

If there were a couple of copies of the fsxnet.* in that directory, it might have been trying to use the incorrect .tic file. See what happens when Paul hatches out the next nodelist/infopack.


---

Black Panther(RCS)
a.k.a. Dan Richter
Sysop - Castle Rock BBS
telnet://bbs.castlerockbbs.com
http://www.castlerockbbs.com
The sparrows are flying again....

--- Mystic BBS v1.12 A42 2018/12/30 (Linux/64)
* Origin: Castle Rock BBS - bbs.castlerockbbs.com (21:1/186)

Spoke too quickly.

And again. They were tossed in badfile for CRC offenses:

+ Jan 27 04:06:03 Tossing FSXNET.tic
+ Jan 27 04:06:03 File FSXNET.Z32 Area FSX_NODE From 21:4/100
- Jan 27 04:06:03 CRC 9d8fb9e2 TIC 9D8FB9E2
! Jan 27 04:06:03 Bad file CRC (got 9d8fb9e2); Moved to /mystic/files/badfile/

FSXNET.tic has:

Replaces fsxinfo.zip
From 21:4/100
To 21:4/123
Origin 21:1/1
Size 98677
Crc A9163DA6

So 9d8fb9e2 is not the same as 9D8FB9E2?

+=====================+-+=======+----------------------------------------
| *H:U:M:O:N:G:O:U:S* | | B:B:S | nathanael : jenandcal.familyds.org:2323 +=====================+-+=======+----------------------------------------

--- Mystic BBS v1.12 A41 2018/12/27 (Raspberry Pi/32)
* Origin: *HUMONGOUS* BBS (21:4/123)

On 27 Jan 2019, nathanael pondered and said...

+ Jan 27 04:06:03 Tossing FSXNET.tic
+ Jan 27 04:06:03 File FSXNET.Z32 Area FSX_NODE From 21:4/100
- Jan 27 04:06:03 CRC 9d8fb9e2 TIC 9D8FB9E2
! Jan 27 04:06:03 Bad file CRC (got 9d8fb9e2); Moved to /mystic/files/badfile/

FSXNET.tic has:

Replaces fsxinfo.zip
From 21:4/100
To 21:4/123
Origin 21:1/1
Size 98677
Crc A9163DA6

So 9d8fb9e2 is not the same as 9D8FB9E2?

Hmm... have not hit that one before...

Best, Paul

--- E:avon@bbs.nz ------ W:bbs.nz ---
--- K:keybase.io/avon --------------

--- Mystic BBS v1.12 A42 2018/12/30 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

I experienced a setup issue with my copy of Mystic, when processing the incoming TIC files, the CRC in the TIC file and the one computed by MUTIL
were different so both FSXNET.* and FSXINFO.zip were dumped in the badfile directory. I had to turn off checking CRC to get them too import which is
IMO not a good thing.

Just thought I'd let y'all know.

-=[crd]=-

--- Mystic BBS v1.12 A41 2018/12/27 (Windows/32)
* Origin: The Dragon's Gate BBS (21:4/146)

If there were a couple of copies of the fsxnet.* in that directory, it might have been trying to use the incorrect .tic file. See what happens when Paul hatches out the next nodelist/infopack.

Dunno about fsxnet.*, but GDYNWIN.ZIP came in a couple of hours ago and it
too went into badfile:

+ Jan 27 06:14:02 File GDYNWIN.ZIP Area FSX_DOOR From 21:4/100
- Jan 27 06:14:02 CRC cf1485f3 TIC CF1485F3
! Jan 27 06:14:02 Bad file CRC (got cf1485f3); Moved to /mystic/files/badfile/

So I manually edited the tic file, lowercased the crc value, and moved them back to echomail/in/. mutil tossed them back in badfile/ again, this time
with:

- Jan 27 07:58:53 CRC cf1485f3 TIC cf1485f3
! Jan 27 07:58:53 Bad file CRC (got cf1485f3); Moved to /mystic/files/badfile/

For some reason cf1485f3 != cf1485f3

+=====================+-+=======+----------------------------------------
| *H:U:M:O:N:G:O:U:S* | | B:B:S | nathanael : jenandcal.familyds.org:2323 +=====================+-+=======+----------------------------------------

--- Mystic BBS v1.12 A41 2018/12/27 (Raspberry Pi/32)
* Origin: *HUMONGOUS* BBS (21:4/123)

incoming TIC files, the CRC in the TIC file and the one computed by MUTIL were different so both FSXNET.* and FSXINFO.zip were dumped in the
badfile directory. I had to turn off checking CRC to get them too

Yay, I'm not the only one.

But the puzzler is that the CRCs are NOT different: most recently I got this
in my logs:

+ Jan 27 06:14:02 File GDYNWIN.ZIP Area FSX_DOOR From 21:4/100
- Jan 27 06:14:02 CRC cf1485f3 TIC CF1485F3
! Jan 27 07:58:53 Bad file CRC (got cf1485f3); Moved to /mystic/files/badfile/

+=====================+-+=======+----------------------------------------
| *H:U:M:O:N:G:O:U:S* | | B:B:S | nathanael : jenandcal.familyds.org:2323 +=====================+-+=======+----------------------------------------

--- Mystic BBS v1.12 A41 2018/12/27 (Raspberry Pi/32)
* Origin: *HUMONGOUS* BBS (21:4/123)

On 27 Jan 2019, nathanael pondered and said...

Dunno about fsxnet.*, but GDYNWIN.ZIP came in a couple of hours ago and
it too went into badfile:

+ Jan 27 06:14:02 File GDYNWIN.ZIP Area FSX_DOOR From 21:4/100
- Jan 27 06:14:02 CRC cf1485f3 TIC CF1485F3
! Jan 27 06:14:02 Bad file CRC (got cf1485f3); Moved to /mystic/files/badfile/

So I manually edited the tic file, lowercased the crc value, and moved them back to echomail/in/. mutil tossed them back in badfile/ again,
this time with:

- Jan 27 07:58:53 CRC cf1485f3 TIC cf1485f3
! Jan 27 07:58:53 Bad file CRC (got cf1485f3); Moved to /mystic/files/badfile/

To add to this, the file is created by a separate tool ex Mystic and it lands in Mystic NET 1 HUB and is then tossed onwards.

At that points things seem fine

[snip]

----------------- MUTIL v1.12 A42 2018/12/30 Sun, Jan 27 2019 (loglevel 3)
+ Jan 27 11:03:16 Startup using mailin.ini
- Jan 27 11:03:16 EXEC ImportEchoMail
- Jan 27 11:03:16 EXEC FileToss
+ Jan 27 11:03:17 Process: Toss FDN/TIC Files
+ Jan 27 11:03:17 Tossing 128kbuu2.tic
- Jan 27 11:03:17 Unknown Key (CREATED) Value (Created by HTick,
written by Gabriel Plutzar)
- Jan 27 11:03:17 Unknown Key (LDESC) Value (LDesc +----------------------------+)
- Jan 27 11:03:17 Unknown Key (LDESC) Value (LDesc | Galactic Dynasty |)
- Jan 27 11:03:17 Unknown Key (LDESC) Value (LDesc | by
|)
- Jan 27 11:03:17 Unknown Key (LDESC) Value (LDesc | Andrew
Pamment |)
- Jan 27 11:03:17 Unknown Key (LDESC) Value (LDesc +----------------------------+)
- Jan 27 11:03:17 Unknown Key (LDESC) Value (LDesc | Galactic Dynasty
is a BBS |)
- Jan 27 11:03:17 Unknown Key (LDESC) Value (LDesc | door game similar
to Solar |)
- Jan 27 11:03:17 Unknown Key (LDESC) Value (LDesc | Realms Elite.
|)
- Jan 27 11:03:17 Unknown Key (LDESC) Value (LDesc |
|)
- Jan 27 11:03:17 Unknown Key (LDESC) Value (LDesc | It is interBBS capable and |)
- Jan 27 11:03:17 Unknown Key (LDESC) Value (LDesc | opensource.
|)
- Jan 27 11:03:17 Unknown Key (LDESC) Value (LDesc |
|)
- Jan 27 11:03:17 Unknown Key (LDESC) Value (LDesc | v0.9.3-dev WIN32 |)
- Jan 27 11:03:17 Unknown Key (LDESC) Value (LDesc +----------------------------+)
- Jan 27 11:03:17 Unknown Key (ORIGIN) Value (Origin 21:1/1)
- Jan 27 11:03:17 Unknown Key (PATH) Value (Path 21:1/1 1548540101 Sat Jan 26 22:01:41 2019 UTC htick/w32-mvcdll 1.9.0-cur 17-08-15)
- Jan 27 11:03:17 Unknown Key (SEENBY) Value (Seenby 21:1/1)
- Jan 27 11:03:17 Unknown Key (SEENBY) Value (Seenby 21:1/2)
+ Jan 27 11:03:17 File GDYNWIN.ZIP Area FSX_DOOR From 21:1/1
- Jan 27 11:03:17 Replace "GDYNWIN.ZIP"
+ Jan 27 11:03:17 Replacing GDYNWIN.ZIP
+ Jan 27 11:03:17 Added to BBS Doors, Games etc.
+ Jan 27 11:03:17 Export to 21:1/101 c:\mystfsx\filebox\agency\fsxnet\

[snip]

+ Jan 27 11:03:17 Scanning Hatches
+ Jan 27 11:03:17 Results: 1 import, 57 toss, 0 hatch, 0 bad in 0.19s

[snip]

I checked the file and tic tossed to Agency, those logs show

[snip]

----------------- MUTIL v1.12 A42 2018/12/30 Sun, Jan 27 2019 (loglevel 3)
+ Jan 27 11:04:19 Startup using mailin.ini
- Jan 27 11:04:19 EXEC ImportEchoMail
- Jan 27 11:04:19 EXEC FileToss
+ Jan 27 11:04:19 Process: Toss FDN/TIC Files
+ Jan 27 11:04:19 Tossing GDYNWIN.tic
- Jan 27 11:04:19 Unknown Key (CREATED) Value (Created by HTick,
written by Gabriel Plutzar)
- Jan 27 11:04:19 Unknown Key (LDESC) Value (LDesc +----------------------------+)
- Jan 27 11:04:19 Unknown Key (LDESC) Value (LDesc | Galactic Dynasty |)
- Jan 27 11:04:19 Unknown Key (LDESC) Value (LDesc | by
|)
- Jan 27 11:04:19 Unknown Key (LDESC) Value (LDesc | Andrew
Pamment |)
- Jan 27 11:04:19 Unknown Key (LDESC) Value (LDesc +----------------------------+)
- Jan 27 11:04:19 Unknown Key (LDESC) Value (LDesc | Galactic Dynasty
is a BBS |)
- Jan 27 11:04:19 Unknown Key (LDESC) Value (LDesc | door game similar
to Solar |)
- Jan 27 11:04:19 Unknown Key (LDESC) Value (LDesc | Realms Elite.
|)
- Jan 27 11:04:19 Unknown Key (LDESC) Value (LDesc |
|)
- Jan 27 11:04:19 Unknown Key (LDESC) Value (LDesc | It is interBBS capable and |)
- Jan 27 11:04:19 Unknown Key (LDESC) Value (LDesc | opensource.
|)
- Jan 27 11:04:19 Unknown Key (LDESC) Value (LDesc |
|)
- Jan 27 11:04:19 Unknown Key (LDESC) Value (LDesc | v0.9.3-dev WIN32 |)
- Jan 27 11:04:19 Unknown Key (LDESC) Value (LDesc +----------------------------+)
- Jan 27 11:04:19 Unknown Key (ORIGIN) Value (Origin 21:1/1)
- Jan 27 11:04:19 Unknown Key (PATH) Value (Path 21:1/1 1548540101 Sat Jan 26 22:01:41 2019 UTC htick/w32-mvcdll 1.9.0-cur 17-08-15)
- Jan 27 11:04:19 Unknown Key (SEENBY) Value (Seenby 21:1/1)
- Jan 27 11:04:19 Unknown Key (SEENBY) Value (Seenby 21:1/2)
- Jan 27 11:04:19 Unknown Key (PATH) Value (Path 21:1/100 Sun Jan 27 11:03:17 2019 UTC Mystic/1.12 A42)
- Jan 27 11:04:19 Unknown Key (SEENBY) Value (Seenby 21:1/100)
- Jan 27 11:04:19 Unknown Key (SEENBY) Value (Seenby 21:1/101)

[snip]

+ Jan 27 11:04:19 File GDYNWIN.ZIP Area FSX_DOOR From 21:1/100
- Jan 27 11:04:19 Replace "GDYNWIN.ZIP"
+ Jan 27 11:04:19 Replacing GDYNWIN.ZIP
+ Jan 27 11:04:19 Added to BBS Doors, Games etc.
+ Jan 27 11:04:19 Scanning Hatches
+ Jan 27 11:04:19 Results: 1 import, 0 toss, 0 hatch, 0 bad in 0.08s

[snip]

So from this end, using two windows based Mystic systems the file was
imported into the HUB, tossed out to other nodes and at 1/101 import OK.

But yeah I agree something is up.

Best, Paul

--- E:avon@bbs.nz ------ W:bbs.nz ---
--- K:keybase.io/avon --------------

--- Mystic BBS v1.12 A42 2018/12/30 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 27 Jan 2019, nathanael said the following...

- Jan 27 07:58:53 CRC cf1485f3 TIC cf1485f3
! Jan 27 07:58:53 Bad file CRC (got cf1485f3); Moved to /mystic/files/badfile/

For some reason cf1485f3 != cf1485f3

I know there was an issue with A40, I believe it was, where the crc check was messed up. It was not seeing the uppercase and lowercase were the same. It's possible this is still an issue with some of the releases...

Maybe g00r00 will be able to comment on this...


---

Black Panther(RCS)
a.k.a. Dan Richter
Sysop - Castle Rock BBS
telnet://bbs.castlerockbbs.com
http://www.castlerockbbs.com
The sparrows are flying again....

--- Mystic BBS v1.12 A42 2018/12/30 (Linux/64)
* Origin: Castle Rock BBS - bbs.castlerockbbs.com (21:1/186)

On 27 Jan 2019, Avon said the following...

So from this end, using two windows based Mystic systems the file was imported into the HUB, tossed out to other nodes and at 1/101 import OK.

But yeah I agree something is up.

I can also show it was tossed on the hub 4 system, also Windows based, and tossed out from there. Also, on the 1/186 system, these files are tossing
fine, running Linux/64.

The only thing I can think of, is what versions of Mystic are these nodes running? Is it possible there is an issue still with the RPi compile, as I
know that one of them is running RPi A41?


---

Black Panther(RCS)
a.k.a. Dan Richter
Sysop - Castle Rock BBS
telnet://bbs.castlerockbbs.com
http://www.castlerockbbs.com
The sparrows are flying again....

--- Mystic BBS v1.12 A42 2018/12/30 (Linux/64)
* Origin: Castle Rock BBS - bbs.castlerockbbs.com (21:1/186)

I know there was an issue with A40, I believe it was, where the crc
check was messed up. It was not seeing the uppercase and lowercase were the same. It's possible this is still an issue with some of the

I had that thought, so I copy-pasted the generated crc value from the mutil
log into the tic, then tossed everything back into echomail/in/. Still ended
up in badfile.

+=====================+-+=======+----------------------------------------
| *H:U:M:O:N:G:O:U:S* | | B:B:S | nathanael : jenandcal.familyds.org:2323 +=====================+-+=======+----------------------------------------

--- Mystic BBS v1.12 A41 2018/12/27 (Raspberry Pi/32)
* Origin: *HUMONGOUS* BBS (21:4/123)

On 26 Jan 2019, Black Panther said the following...

I know there was an issue with A40, I believe it was, where the crc
check was messed up. It was not seeing the uppercase and lowercase were the same. It's possible this is still an issue with some of the releases...

I had that issue here when I first joined fsxNet, and I'm still running A41.
It happened with the first nodelist hatched, but it's been ok since.

Fireball

--- Mystic BBS v1.12 A41 2018/12/27 (Linux/64)
* Origin: Fireball Express!!! Mystic Edition (21:4/145)

On 26 Jan 2019, Black Panther pondered and said...

I can also show it was tossed on the hub 4 system, also Windows based,
and tossed out from there. Also, on the 1/186 system, these files are tossing fine, running Linux/64.

OK cool thanks...

The only thing I can think of, is what versions of Mystic are these nodes running? Is it possible there is an issue still with the RPi compile, as
I know that one of them is running RPi A41?

Good questions... the guys can let us know.

Best, Paul

--- E:avon@bbs.nz ------ W:bbs.nz ---
--- K:keybase.io/avon --------------

--- Mystic BBS v1.12 A42 2018/12/30 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

Just FYI, I've disabled CRC checks for the time being, and files are tossing properly.

+=====================+-+=======+----------------------------------------
| *H:U:M:O:N:G:O:U:S* | | B:B:S | nathanael : jenandcal.familyds.org:2323 +=====================+-+=======+----------------------------------------

--- Mystic BBS v1.12 A41 2018/12/27 (Raspberry Pi/32)
* Origin: *HUMONGOUS* BBS (21:4/123)

So 9d8fb9e2 is not the same as 9D8FB9E2?

That may be a logging bug because in the .TIC it shows:

Crc A9163DA6

And Mystic is saying the file is:

! Jan 27 04:06:03 Bad file CRC (got 9d8fb9e2); Moved to

It certainly seems like something is off thats for sure.

--- Mystic BBS v1.12 A42 2019/01/25 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

I know there was an issue with A40, I believe it was, where the crc
check was messed up. It was not seeing the uppercase and lowercase were the same. It's possible this is still an issue with some of the releases...

No that wasn't the issue. The CRC is an integer value so its actually a
number not a string. Its converted to a hex string when its logged.

I will take a look at this as soon as I can. I am pretty behind on messages
as I am way overloaded at work. It'll be a miracle of I can hit my deadlines even without working on Mystic. Hopefully in the next couple of weeks things will slow down again for me but I will try to look at this issue this weekend.

--- Mystic BBS v1.12 A42 2019/01/25 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

On 30 Jan 2019, g00r00 said the following...

I know there was an issue with A40, I believe it was, where the crc check was messed up. It was not seeing the uppercase and lowercase we the same. It's possible this is still an issue with some of the releases...

No that wasn't the issue. The CRC is an integer value so its actually a number not a string. Its converted to a hex string when its logged.

Ok. I was going from memory, which we all know isn't as good as it was 25
years ago... :)

I will take a look at this as soon as I can. I am pretty behind on messages as I am way overloaded at work. It'll be a miracle of I can
hit my deadlines even without working on Mystic. Hopefully in the next couple of weeks things will slow down again for me but I will try to
look at this issue this weekend.

Ouch. I hope things slow down a bit for you. You need some time to breath and relax.


---

Black Panther(RCS)
a.k.a. Dan Richter
Sysop - Castle Rock BBS
telnet://bbs.castlerockbbs.com
http://www.castlerockbbs.com
The sparrows are flying again....

--- Mystic BBS v1.12 A42 2018/12/30 (Linux/64)
* Origin: Castle Rock BBS - bbs.castlerockbbs.com (21:1/186)

On 27 Jan 2019, nathanael said the following...

And again. They were tossed in badfile for CRC offenses:

+ Jan 27 04:06:03 Tossing FSXNET.tic
+ Jan 27 04:06:03 File FSXNET.Z32 Area FSX_NODE From 21:4/100
- Jan 27 04:06:03 CRC 9d8fb9e2 TIC 9D8FB9E2
! Jan 27 04:06:03 Bad file CRC (got 9d8fb9e2); Moved to /mystic/files/badfile/

I had that exact same issue on Win32. I finally just turned off the CRC checking as I have no idea why the CRC isn't matching up.

--
-=[crd]=-
The Renegade aka Lormar aka Cory Daehn
The Dragon's Gate BBS, La Junta, CO, USA

--- Mystic BBS v1.12 A41 2018/12/27 (Windows/32)
* Origin: The Dragon's Gate BBS bbs.mayorlormar.com (21:4/146)