Quote:
Originally Posted by Yil
paja1: I'm considering a requested feature of allowing the server to startup as if the site was closed. A new option to the site close command would make it carry over until it was removed even if restarted. Probably just via a simple file being created in the system dir with the reason. Assuming I do this I don't see why I can't use similar login logic and let the server startup normally and respond with a "server coming up" message as the closed message (provided you haven't set a real one) while preloading finishes. Perhaps even applying a different CloseExempt parameter. I'm also looking at ways to prevent LIST/MLST from timing out during 2+ minute listings by just spitting out 200- keep alive messages although it's a bit tricky to do. The real problem is STAT/NLST is very specific about what you can return so I'm looking into faking out the "." entry or something if needed. Preloading makes logins appear snappier when connecting to a newly started server but were really designed to get around 2+ minute initial directory listings which clients timeout...
|
Thanks.. sounds like a good solution... even i can understand that implementation of 'progress' messages can be quite tricky.. and i think (maybe) not necesary.
Quote:
Originally Posted by Yil
Event OnUploadComplete returns invalid CRC32 value? Provided you haven't disabled computing it in the .ini file I think it should be working fine. I remember ioSFV used it for a while and I'm pretty sure ioNinja uses it now. I added support somewhere like v6.3 or so that it would compute the CRC32 value over the whole file and not just the uploaded section as it did before that which made a difference for resumed files. The builtin XCRC (XCRC32?) FTP command is special cased though. It will return the CRC32 value for the uploaded file the first time it is called immediately after uploading (so clients can check if the file transferred OK), however this might not be the same as the file on disk if the zipscript modified (i.e. added/stripped .nfo files) so you can call it again and it will give you the disk based result on all further calls. If the OnUploadComplete CRC32 value when called is different than that called by the [crc32] command then that indicates a problem. Is it reproducible? I can't believe ioNinja would work without it being correct at least most of the time... Nothing weird like attempting to upload a single file via multiple connections going on?
|
Unfortunately I'm not able to reproduce it any more... and seems like it works well atm actually.
I'd experienced this on text file (*.bat) but works fine with this one as well.. dunno why it returns wrong values at that point... but i restarted ioFTPD serveral time between, so anything could happen.
Thanks for you quite good answer and explanation.
Pavel