* Reply to message originally in area CarbonArea

Hello Vince!

Wed Sep 11 2013, Vince Coen wrote to Gert Andersen:

There seem to be some bad by when mbse is hatch out files or something
other release files. When mbse hatch files out look it like that there
is some miss or error between .tic files and the file. I have checked
it out by hatch a file from my node 2 to my node 1. example is that
the files size is 444455 and in the tic have is the line size korrekt
with 444455, but when the file and tic is got to my node 1 and my
husky htick is trying import the file is the crc error between the
file and tic onfo. htick said that the zise of file wrong in the tic
file and it should be 00000000

The same is happen when I getting files from RJ Clay and the file is
not been imported and processed.

Hmm, I will check with my uplink to see if she had a problem with files
I have
hatched however I must point out that I do NOT split them up as mbse
seems to
have problems dealing with multi rar files if the tic file for the .rar
file is not the lowest number in sequence.

I tried to let my node 2 of mbse hatch a new golded snapshot to my main node in
a upstream file echo to my self and the file was a zip file and when my htick should import and process the tic and the file got I the error self if all look
fine in the tic file and between file but the process crc gives error and says that the file is in 00000000 bytes and the bytes size in the tic and the file is the same, and if I then in the tic put in size 00000000 is it been processed.
The same is happen when Jame is stn4000 segment out htick comes up with same error.

mbse has no error by self process and import files and not rar split files. You
can se out from my file announcing from 2:230/152 and 2:230/150.1

Take care,
Gert

- Get the best with linux -

--- Msged/LNX 6.2.0 (Linux/2.6.39-gentoo-r1 (x86_64))
* Origin: * One step from heaven is not enough * (2:230/150)

Hello Gert!

11 Sep 13 19:31, you wrote to me:

There seem to be some bad by when mbse is hatch out files or something
other release files. When mbse hatch files out look it like that there
is some miss or error between .tic files and the file. I have checked
it out by hatch a file from my node 2 to my node 1. example is that
the files size is 444455 and in the tic have is the line size korrekt
with 444455, but when the file and tic is got to my node 1 and my
husky htick is trying import the file is the crc error between the
file and tic onfo. htick said that the zise of file wrong in the tic
file and it should be 00000000

The same is happen when I getting files from RJ Clay ad the file is
not been imported and processed.

Having checked with my uplink (Janis) there is no problems with the files I have produced with mbse, e.g., the file size matches with the size given in the
tic file along with the crc values.

That includes rest of the tic file contents.

I suspect that the issue is with htick so :

1. Look at the files going into htick including the size and crc data
2. Check what htick is reporting in the log file/s
3. If needed increase the reporting level (full error data etc).
4. Change your processor, mbse handles it fine.

Regardless, the problem is with htick, heck it is very old code.


Vince

--- Linux/Mbse/GoldED+/LNX 1.1.5-b20120229
* Origin: Air Applewood, The Linux Gateway to the UK (2:250/1)

Hello Vince!

12 Sep 13 23:07, you wrote to Gert Andersen:

I suspect that the issue is with htick so :

oh sure ? :)

if crc pass then file size is diff ?

1. Look at the files going into htick including the size and crc data

htick does imho not check size in tic files, why should it ?

2. Check what htick is reporting in the log file/s

+1

3. If needed increase the reporting level (full error data etc).

+10000

4. Change your processor, mbse handles it fine.

+1

Regardless, the problem is with htick, heck it is very old code.

yep :)


Benny


--- GoldED+/LNX 1.1.5-b20130910
* Origin: me at junc dot org (2:230/0)

* Reply to message originally in area CarbonArea

Hello Vince!

Thu Sep 12 2013, Vince Coen wrote to Gert Andersen:

There seem to be some bad by when mbse is hatch out files or something
other release files. When mbse hatch files out look it like that there
is some miss or error between .tic files and the file. I have checked
it out by hatch a file from my node 2 to my node 1. example is that
the files size is 444455 and in the tic have is the line size korrekt
with 444455, but when the file and tic is got to my node 1 and my
husky htick is trying import the file is the crc error between the
file and tic onfo. htick said that the zise of file wrong in the tic
file and it should be 00000000

The same is happen when I getting files from RJ Clay ad the file is
not been imported and processed.

Having checked with my uplink (Janis) there is no problems with the
files I
have produced with mbse, e.g., the file size matches with the size
given in
the
tic file along with the crc values.

That includes rest of the tic file contents.

I suspect that the issue is with htick so :

1. Look at the files going into htick including the size and crc data
2. Check what htick is reporting in the log file/s
3. If needed increase the reporting level (full error data etc).
4. Change your processor, mbse handles it fine.

Regardless, the problem is with htick, heck it is very old code.

I have think a little over it and it can both be mbse and htick by their conversion, like the file is 4806 bytes and i the tic is the same size 4806 and
hticks crc said it should be 00000000 so if the mbse tic file read the size of 48060000 instead of 00004806.


Take care,
Gert

- Get the best with linux -

--- Msged/LNX 6.2.0 (Linux/2.6.39-gentoo-r1 (x86_64))
* Origin: The KofoBBS at http://www.kofobbs.dk (2:230/150)

On Fri, 13 Sep 2013, Benny Pedersen wrote to Vince Coen:

I suspect that the issue is with htick so :

oh sure ? :)

if crc pass then file size is diff ?

or otherwise modified from original...

1. Look at the files going into htick including the size and crc data

htick does imho not check size in tic files, why should it ?

all tic processors must check size and checksum... size to know if the file is complete or altered and then md5 to know if file of same size has been modified...

filesize as first check is no problem and faster than using md5 to detect such...

)\/(ark


* Origin: (1:3634/12)

On Fri, 13 Sep 2013, Gert Andersen wrote to Vince Coen:

I have think a little over it and it can both be mbse and htick by
their conversion, like the file is 4806 bytes and i the tic is the
same size 4806 and hticks crc said it should be 00000000 so if the
mbse tic file read the size of 48060000 instead of 00004806.

where do these unwanted zero come from?? they should not exist in the TIC file in the first place...

)\/(ark


* Origin: (1:3634/12)

Hello Gert!

13 Sep 13 09:59, you wrote to me:

Regardless, the problem is with htick, heck it is very old code.

I have think a little over it and it can both be mbse and htick by
their conversion, like the file is 4806 bytes and i the tic is the
same size 4806 and hticks crc said it should be 00000000 so if the
mbse tic file read the size of 48060000 instead of 00004806.

You NEED to see what is being processed by htick however, I have NEVER heard of
a problem in this arena.

I still say it is related to htick but alnother small point is that is htick is
running under DOS or possibly Windows the actual file size could and no doubt will be larger to match a cluster size which linux / OS-2 does not do.

Regardless the tick processor should NOT be using that size but the one reported by the tic file along with the o/p from the crc check.

As I said I think it is an issue with htick using a poor API call to get the file size and possibly along with the platform it is running on.


Vince

--- Linux/Mbse/GoldED+/LNX 1.1.5-b20120229
* Origin: Air Applewood, The Linux Gateway to the UK (2:250/1)