bad files and ioZS

[talktwo]

I have a little problem and I?m wondering if anyone else has the same problem. When uploading .rar files I always get at least one or two .bad files, but it?s only when I upload large .rar files 50mb size. Anyone heard about this problem or experienced it?

That was posted by Bubben a while back, and I am currently experiencing the same problem.

ioZS seems to create .bad files every so often, and no matter where i upload from or how many times i upload a particular file, it will always be .bad ... however, when i use a different ftp daemon that file will work fine and i can extract the files ... any insight into this? thank you.

ioZS v1.08 ... i know there's a new version out, I've tested it and it gives the same errors ... it doesn't only happen on one drive either ... it's on multiple drives.

[neoxed]

The CRC value is calculated by ioFTPD and passed to ioZS, all ioZS does it simply match the CRC with one for the corresponding filename in the .sfv. A foolproof procedure to some extent.

Can you try testing the CRC of that file manually, using a SFV file verification tool (i.e. FlashSFV). Be sure to rename the file first though, removing the .bad extension.

Which version of ioFTPD are you using? I'm hoping Beta-5.8.5r since you're a registered user. (There was a problem with ioFTPD passing the wrong CRC in one of the Beta-5.1-2.x releases.)

[talktwo]

thank you for the prompt response ... here's the kicker:

ioFTPD download of file: sfv check is bad with ioZS and sfv check is bad with flashSFV

BPFTPD download of file: to a different drive (i.e. C:) sfv check is good with flashSFV

BPFTPD download of file: to the folder where the application is (i.e. where it's SUPPOSED to go) sfv check is GOOD using flashSFV. Upon logging into that folder using ioFTPD and conducting a 'site rescan' command, file is GOOD ...

it only occurs when I FXP from site1 to ioFTPD. When I transfer the file over from BPFTPD and do a rescan, everything is good.

[Unique]

bftpd sux if your fxping from it, it had years and years of malfunctioning fxp support (usually hangs on small files too with error:error message) :rolleyes:

[bizniz]

if the file was resumed then io passes crc of resumed bit, not crc of complete file, so maybe this is the prob.

ioZS maybe doesnt rescan failed files...

[talktwo]

thank you for your responses, however, neither were the answers I was looking for. I also believe that you missed my point of using BPFTPD. Here's the case as it stands now (using full file download as examples, not resume) both going into the same folder.

NeoXed ... I have done what you have suggested and here are the results:

Site 1 to ioFTPD: ioZS -> file check = BAD flashSFV -> file check = BAD

Site 1 to BPFTPD: no sfv checker flashSFV -> file check = GOOD on 'site rescan' using ioFTPD ioZS -> file check = GOOD

Here is the information from Beyond Compare2:

Comparing files mo-amsw2.r05 and MO-AMSW2.R05.BAD
00DA8EF7: 86 C0
00DA8EF8: 16 A8
00DA8EF9: 54 00
00DA8EFA: 7D 64

what the implications of this are, I am not too sure. Basically, I would like to know the reason as to why when Site 1 fxp's to ioFTPD, the file turns out bad. But when Site 1 fxp's to BPFTPD then is RESCANNED by ioFTPD, the file turns out good.:confused: :confused:

[neoxed]

I spoke with you on IRC earlier; you mentioned that the transfers were all done locally (i.e. localhost a.k.a. 127.0.0.1). By that I mean, both FTP servers are on the same computer. (Just to make sure there are no misunderstandings.)

When you refer to "Site 1" is that a remote FTP server, or an FTP server on your computer?

On your ioFTPD installation, try disabling all post/pre scripts and OnUploadComplete events - any script that would interact with an uploaded file.

In addition, if you have some free time, could you try the latest Serv-U (5.2 as of this post) instead of Bulletproof.

(If there's still a problem with corrupt files with all scripts disabled, we can conclude this isn't an ioZS issue. In which case, I will move this thread to another forum category.)

Good luck! :)

[bizniz]

are any of these crc's having preceding '0' in the hex value in the sfv?

[Stardog]

Just to clarify how ioZS checks the SFV:

CRC value is passed from ioFTPD to ioZS, ioZS compares the CRC from io to the CRC in the SFV (if present, otherwise it just stores it until the SFV is upped). If the CRC passed from io does not match the CRC from the SFV, then it reads the file and calculates the CRC itself and compares again with the SFV, if they still don't match, then the file is marked as bad. So in a sense, the file is checked twice before marking it bad.

hmm, bizniz makes a good point, what is the CRC value of the bad files?

[talktwo]

NeoXed -

"Site 1" is a remote ftp server, not local. I will disable all pre/post events that may interact with the files later tonight, and test with ServU as well.

I will post the results of that test later on.

Also, if you could explain to me the significance of my compare files results, that would be much appreciated, thanks.

Bizniz -

I don't believe they precede with 0's in the sfv, I will have to double check that tonight though.

[Mouton]

The sfv file and zipscript are not relevant.
The thing is, the file itself is different when it's transfered by io and when it's transfered by bpftpd.
I would say try a clean io package, see if the file arrives bad too.
Are both ftpd using the same nic on your pc ?
I would also try to transfer the files multiple times to io, and diff it with the good file to see if it's always the same bytes that are different, or if the diff are random.

All in all, i'm pretty sure it's a hardware/drivers issue... most probably hardware.

[Stardog]

Originally posted by Mouton
The sfv file and zipscript are not relevant.
The thing is, the file itself is different when it's transfered by io and when it's transfered by bpftpd.
I would say try a clean io package, see if the file arrives bad too.
Are both ftpd using the same nic on your pc ?
I would also try to transfer the files multiple times to io, and diff it with the good file to see if it's always the same bytes that are different, or if the diff are random.

All in all, i'm pretty sure it's a hardware/drivers issue... most probably hardware.

Yup, I had this on a system I was overclocking...Soon as the proc was put to normal specs problem went away completely...

[talktwo]

Hmmm thanks for the input. I have tested out downloading the file from Site 1 (remote location) to that same folder using ServU as the daemon, flashSFV shows file is good, rescanning in ioFTPD shows file is good. But still, even downloading from multiple sites to ioFTPD that same file is still corrupt.

As NeoXed did bring to my attention the other day, the only thing that has changed in my PC environment is changing of my router, I used to run a Linksys router and never had this issue. I had changed my router the day before these errors started occuring to a DLink DI-604. In addition to that, I do not overclock my system.

I will consider doing a fresh install of ioFTPD if all else fails to rectify the situation. Thank you.

[talktwo]

thank you all for your reponses. I have gone ahead and reinstalled ioFTPD, and everything seems to be working fine for now. All except the !bw, !speed, !leechers etc commands on dzsbot ... I have searched the forums and have read the following posts:

http://www.ioftpd.com/board/showthread.php?s=&postid=12457#post12457

http://www.ioftpd.com/board/showthread.php?s=&threadid=901

however, neither of them had worked for me as a) I do not use ioBanana b) I do not use Warchive ... If you could enlighten me as to why the !bw etc. commands are displaying no users, that would be much appreciated, thank you.

[VERSION] + ioFTPD 5-8-5r - dZSbot 1.15 - Eggdrop 1.6.13+sharefix - ioA 1.1.9 - ioZS 2.05

[talktwo]

ok problem fixed :banana: :banana: thanks again you guys ... especially for being so patient ;-)

[talktwo]

don't you hate when you haven't fully tested then jump to conclusions? Anyways, I'm still getting those .bad files ... and NeoXed was right ... it is my router that's causing the issue ...

Here are the specs: DLink DI-604, 3.39 firmware, and it is DMZ-ed ... anyone have any insights? Let me know, thanks.

[Mouton]

Return it, get a new one.
Shouldn't be too difficult if u say you get corrupted data when transfering files through it!