FTPLogger update, now adds zipcleaning

[FTPServerTools]

Ok I just added a small thing.. Zipcleaning...
How does it work?
Use FTPServerTools.ini..
[Zip]
Clean=TRUE (or FALSE) to actually allow cleaning to happen.
CleanComments=TRUE (or FALSE) to clean the global zip comment
CleanFileComments=TRUE (or FALSE) to clean the file comments of the files in the zip
CleanExtraNfo=TRUE (or FALSE) to clean extra nfo's in the file, the proper nfo will be kept.
SkipFile=c:\program files\zipclean\purge.txt (clean the files mentioned in this skipfile).
KeepFile=c:\program files\ioftpd\scripts\extractnfo.txt (keep these files in the nfo and dont clean them out).

O yes it is fast, due to the point that FTPLogger parses the zipfiles with my own algorithms.

As a nice side effect it corrects some badly created zipfiles by some other tool as well. :p

[Mouton]

Why don't u use the same files as zr-tools for keep/skipfile ?

[Zer0Racer]

Originally posted by FTPServerTools
As a nice side effect it corrects some badly created zipfiles by some other tool as well. :p

And what tool would that be?

Originally posted by Mouton
Why don't u use the same files as zr-tools for keep/skipfile ?

Mouton.. As if I would let him use them ;)

[thewarden]

Originally posted by FTPServerTools
Ok I just added a small thing.. Zipcleaning...



Thanks for the addition to an already great set of addons...

Now to copy and paste some items :)

[FTPServerTools]

There are multiple reasons for that. First there is zipclean, if people use that then the purge.txt file from that is easy to use to remove junk from the zips. Second a keeplist might be handy if one insists on keeping certain files in there. Third the autocleaninf of useless nfo's doesnt even need any skiplist or keeplist. It works all by itself.
Some zipfiles are in a bad format because some tool (dont ask me which I dont know) doesnt adhere to the zip standard.

Such a zipfile looks like (tech talk coming up....):
local file header
local file header
...
central directory header
central directory header
..
end of central directory
central directory header
central directory header
..
end of central directory

Now this is absolutely incorrect. pkunzip will for example immediately yell the file is bad. The solution is easy, cut off the junk and voila no more odd screwy non standard zip....
I think it is probably some nux tool.
A proper zip ends after the zip comment after the first end of central directory...

[Zer0Racer]

Originally posted by FTPServerTools
Third the autocleaninf of useless nfo's doesnt even need any skiplist or keeplist. It works all by itself.


Built-in AI then? Just HOW does it work all by itself?

[Mouton]

file dates ?
if date the file was added is much more than creation date of the zip, u del it ? that could be dangerous if some packer creates a zip and modify it instead of rebuilding it in following hours...

[shufty]

Just wondering if it's possible to to read the file_id.diz, in the same way that it does for the filecount, to create/insert into a directory based on the date also in the file. Would be ideal for 0-day and DOX.

Possibly work by using `onuploadcomplete` to read the file and then move the directory if possible, but only if the dir is 100%.

just a thought ;)

[FTPServerTools]

And yes the file_id.diz can be read (in fact it already is being read completely to parse the count out using some pattern matching similar to project-zs just better).
For the date I would first need to gather the various date formats. It is more tricky then the count tho since 01-02-03 is not always clear, it could be 1 feb 2003 or 2 jan 2003 or even 2002 feb 01 etc... So only an intelligent check with the current date and the point that the current date isnt supposed to be too far away from the diz date could guess the right date. As I looked basically in about 70% I could extract the date from the diz and if not available from the nfo. Those 30% is the problem..

And Mouton I dont use the file dates, it would fail too often since sometimes the dates are several years back or in advance. The algorithm is similar to what I suspect zipclean uses. Try it on a regular release and you'll see it works quite well.

Maybe I can make an OnComplete mover... That might be usefull. It'd have to think about how to implement the date recognition in case of unrecognisable dates (the 30%).

I havent looked into the keep/skipfiels from zr tools. The nfo name is also partially deducted from the dirname. :)

[shufty]

cool, could be a possibility that if it cant be read correctly, to move it to another directory. Would atleast cut down the majority ;)