ioFTPD General New releases, comments, questions regarding the latest version of ioFTPD. |
01-30-2010, 03:17 PM
|
#16
|
Member
Join Date: Dec 2009
Posts: 43
|
can i upgrade to this version from 7.0.3? ![Smile](https://oss.azurewebsites.net/forum/images/smilies/smile.png) ...
|
|
|
01-31-2010, 05:34 AM
|
#17
|
Too much time...
FlashFXP Beta Tester ioFTPD Administrator
Join Date: May 2005
Posts: 1,194
|
The top of the Changelog file included above and in the .zip file itself has a list of files that need replacing and modifications to make to the .ini file to bring it up to date with this release. Normally it's a bit easier to do, but with the underlying TCL library version being upgraded it's a bit more annoying than normal...
|
|
|
01-31-2010, 08:42 AM
|
#18
|
Member
Join Date: Dec 2009
Posts: 43
|
Quote:
Originally Posted by Yil
The top of the Changelog file included above and in the .zip file itself has a list of files that need replacing and modifications to make to the .ini file to bring it up to date with this release. Normally it's a bit easier to do, but with the underlying TCL library version being upgraded it's a bit more annoying than normal...
|
Thank you i shall make a backup, and get to work
|
|
|
01-31-2010, 06:53 PM
|
#19
|
Senior Member
FlashFXP Beta Tester ioFTPD Scripter
Join Date: Sep 2002
Posts: 543
|
Nice work Yil..
|
|
|
02-05-2010, 11:01 AM
|
#20
|
Senior Member
Join Date: May 2007
Posts: 692
|
[resolve list <path>] i would really like it to return the speed of which the file was uploaded along with that, dunno if it's saved or not but that way there is no need to use the .ioftpd file for storing race stats.
__________________
ioNiNJA
|
|
|
02-05-2010, 01:37 PM
|
#21
|
Too much time...
FlashFXP Beta Tester ioFTPD Administrator
Join Date: May 2005
Posts: 1,194
|
o_dog: Interesting... [resolve list] uses the directory listing logic which means it has a wealth of information not available to TCL directly before, but it doesn't have access to anything more than the core code does. The big issue is that the current .ioFTPD file entry structure just doesn't keep transfer stat information. I would agree that it makes a lot of sense for it to do so though. In fact, when you manually delete a file it's supposed to alter a user's stats and it can't properly adjust the time field used to compute a user's average speed because it doesn't have enough data so it's technically a bug too.
So the short answer is the info you want just isn't available right now. The longer answer is it may be possible in the future as there is some unused/reserved space for each file entry in the .ioFTPD file itself that could be made to store that info right now without affecting anything at all. I've already started using that space for the directory entry itself to store the alternate timestamp although that isn't actually being set/looked up by anything yet.
On a more general note. Is there anything besides a way to get the file upload speed (I'll probably keep total transfer time instead of speed) that you think is important to keep on a per-file basis? For instance, I'm still itching for a download counter so I can get an idea of popular stuff.
|
|
|
02-05-2010, 08:22 PM
|
#22
|
Senior Member
Join Date: May 2007
Posts: 692
|
a download counter isn't really nesseceray, write a tcl script and use a sqldb, would keep both stats and downloads and take 10min to write. that could hold info on who downloaded what and when, stats for users over a period of time........ But if i know the people who use ioninja thats not really something they're interested in =)
I can't really think of anything right now that is needed on a per file basis. Really like this command though It should improve the speed of ioNiNJA and especially the speed if it's under heavy load since the waitobject is no longer nessecary.
Have not written much latley but if you implent the speed i'll start up again since this seems fun. Also think i might migrade from using TCL for http requests and use curl, I'm seeing some problem with tcl sockets under ioFTPD.
__________________
ioNiNJA
|
|
|
02-05-2010, 08:30 PM
|
#23
|
Senior Member
Join Date: May 2007
Posts: 692
|
what version of ioninja is in use when lockup bug occour? And check the process list to see if a file called zip or unzip is running.... They seem to be unstable an when called and locking up they seem to freeze ioftpd.
When you get a lockup please check the list and report your findings. If you see it in the list then terminate it and try to login to ioFTPD.
Although using OPENSSL is still a VERY good idea.....
__________________
ioNiNJA
|
|
|
02-06-2010, 01:34 AM
|
#24
|
Too much time...
FlashFXP Beta Tester ioFTPD Administrator
Join Date: May 2005
Posts: 1,194
|
o_dog: I think the general requirement for optional ioFTPD per-file information is really whether or not it might ever get output in regular directory listings... Any script maintained piece of information would require the use of virtual directories to get at. In theory I could see simple numbers or strings in [chattr] fields being used and have toyed with this idea. For example, overloading the user/group fields with MP3/video information in the listings in some directories. I originally added the virtual directory stuff to do things just like that since you can do anything with them, but I am toying with the idea of letting script writers set a few more special [chattr] fields that the server would understand. Of course, what gets output in directory listings would be controlled by the user so standard owner/group information would always be the default. I'd really love to return all of it via MLSD and let the user view what they want but I'm not aware of any client that allows you to view data from newly made up field names in the actual listing itself... I did submit it as a feature request for FlashFxp though
The new v7.1 tcl libraries should acquire the same lock ioFTPD uses when creating sockets/pipes and processes. In theory this should guarantee that inheritable handles don't end up in processes they shouldn't now. I once thought I proved that if that happened and the child process hanged that ioFTPD would stop accepting new connections. It might not have been the full on lockup bug, but it was a bug and it should be gone now.
If we are still having problems (and it looks like we are) then I have no choice but to blame the MS crypto library which is getter rather long in the tooth and not really maintained anymore. It constantly does a lot of stuff that involves the loader lock which is what is getting stuck... I went and grabbed the openSSL code but I haven't found a nice simple example of how to use it with async callbacks like windows/ioFTPD uses yet... If anyone knows of one, drop a link
o_dog: What kind of things are you seeing with TCL sockets? Is the behavior different in v7.1 from say 6.8? Also, what are you using [resolve list] for? It should make walking directory trees really easy for rescanning ![Smile](https://oss.azurewebsites.net/forum/images/smilies/smile.png) Since it handles merged directories it's kinda cool that it solves a lot of edge cases and thus is really useful, but zipscripts dealing with a single regular dir (which is the goal since nobody currently handles anything else) probably don't get any real benefits. Another useful trick is dealing with broken links in the sorted dirs since they would show up now and are easy to spot.
o_dog: Why wouldn't the waitobject be required now? Even if the file transfer speed was server maintained wouldn't a count of outstanding files, race leader, etc all require locking?
|
|
|
02-06-2010, 12:22 PM
|
#25
|
Senior Member
Join Date: May 2007
Posts: 692
|
nah, it's done on the fly, no stats are saved only the file info so no need for the waitobject int he zipscript since it wouldn't have to write anything to the .ioftpd file except sfv and stuff like that.
__________________
ioNiNJA
|
|
|
02-07-2010, 11:32 PM
|
#26
|
Junior Member
Join Date: Jan 2010
Posts: 1
|
sorry im new at this. i just downloaded it, got it working with an eggdrop but i would like a command for irc where i type !search or !dupe on irc like "!search band_name" and it lists like 10 directories in the channel.
i have that nxTools and "site search band_name" works but it would be much more useful if it worked in the channel so my buds wouldnt even have to log in my ftp to see what i got. can anyone help me what I need if there is a script for that.
there is the DupeDirs.db file from nxtools, is there a way to get the eggdrop to list from that?
//edit
nevermind got it, if anyone else needs this script for !search so your buds can see what u got without logging on your ftp get this eggdrop script: http://sites.google.com/site/freeftp...attredirects=0
Last edited by sa0sin; 02-08-2010 at 06:49 PM.
|
|
|
02-10-2010, 04:04 PM
|
#27
|
Senior Member
Join Date: Feb 2006
Posts: 138
|
so.. when can we read a file in use? =)
|
|
|
02-11-2010, 03:24 PM
|
#28
|
Too much time...
FlashFXP Beta Tester ioFTPD Administrator
Join Date: May 2005
Posts: 1,194
|
pion: Think I've mentioned this more than once... I don't plan on trying to add that feature, though others are of course free to do so. Besides your example of very large .rar files there isn't any reason to allow it and lots of reasons you wouldn't want it. In fact, v7 made such a change less likely because it now protects a newly uploaded file from being downloaded until the zipscript has finished processing it. That allows for the adding or stripping of .nfo files from zips without corruption and/or file verification by the zipscript (such as against the .sfv). Then there is the problem of slow uploaders and being stuck with a very slow transfer from a fast FTP because you're essentially limited by the upload speed of the other user. Don't forget the possibility that the upload is interrupted and thus incomplete. Assuming all those problems for the ability to start the transfer faster doesn't seem like a good trade-off to me.
The final straw is the disk fragmentation issue though. I anticipate changing the upload logic to start buffering multiple megabytes at a time so disk writes are very large in an attempt to reduce file fragmentation. That would add more complexity because you would have to check the file and the write buffer before deciding if there was new data to be downloaded... Just not worth it.
|
|
|
02-20-2010, 07:38 AM
|
#29
|
Senior Member
Join Date: Feb 2006
Posts: 138
|
One fairly good reason from my perspective: drftpd and glftpd supports it, which really is the closest comparisons to iofpd. In fact, not being able to move data that only recently got uploaded to the server puts io at a huge disadvantage when it comes to spreading xx bytes in the fastest possible way. When it comes to incompletes and interrupts, they're rarely a problem as they don't really occur that often. In any case, the zipscript would take care of it.
I don't see why you have to buffer up all the data from the upload tho. It should be fine accessing the file from the hdd directly. Example VideoLAN access to a file being written to.
In comparison with glftpd and drftpd, io speeds come out poorly, especially on busy sites where the first bytes that hits the server is likely to get 10+ download requests the same second as file upload starts.
Included, but not limited to:
Rar files (15-500mb)
Small zip files (5mb)
Audio files, both small and large (100mb+)
Video files (15-500mb)
A live example is 200mb getting uploaded in 2s divided in 20 equally large files by multiple threads. This also means that after 2s the files are rendered old, and invaluable for further uploads. In this scenario ioftpd is utterly useless in comparison with drftpd and glftpd... and to be frank, this really is the ioftpd niche 'marked'
I'm not saying ioftpd has to copy/mimic the behaviour of all other daemons out there, but in my opinion it doesn't hurt to stay competetive in enviroments where speed is one of the most important factors.
|
|
|
02-20-2010, 07:59 AM
|
#30
|
Senior Member
Join Date: May 2007
Posts: 692
|
actually it slows things down most of the time. Accessing incomplete files is one reason why some people get stuck on very slow transfers. It also creates alot of incomplete uploads and thus creating unnessecary bw and time. I used to ask for this feature when darkone was writing, back then the bw was an issue for most people, today however the transfers are fast and the routing is the problem. Not granting access to incomplete files is actually a positive, not for individuals racing since they'll lose most races, but as far a speed is concerned it actually speed stuff up. This is a leftover from old that should be stomped out as far as i'm concerned.
__________________
ioNiNJA
|
|
|
Thread Tools |
|
Display Modes |
Rate This Thread |
Linear Mode
|
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -5. The time now is 03:22 AM.
|