Go Back   FlashFXP Forums > > > >

ioFTPD General New releases, comments, questions regarding the latest version of ioFTPD.

Reply
 
Thread Tools Rating: Thread Rating: 5 votes, 4.40 average. Display Modes
Old 07-22-2011, 09:40 AM   #76
o_dog
Senior Member
 
Join Date: May 2007
Posts: 692
Default

just thought i'd mention a new alpha release of ioninja is up at:
https://oss.azurewebsites.net/forum/new-sc...8-ioninja.html

I need people to report bugs and try it. have fun
__________________
ioNiNJA
o_dog is offline   Reply With Quote
Old 07-24-2011, 05:03 PM   #77
Yil
Too much time...
FlashFXP Beta Tester
ioFTPD Administrator
 
Join Date: May 2005
Posts: 1,194
Default

I'll have a new bugfix release out in a day or so that will fix the NTFS junction issues.
Yil is offline   Reply With Quote
Old 07-25-2011, 07:07 PM   #78
o_dog
Senior Member
 
Join Date: May 2007
Posts: 692
Default

whats wrong with them?
__________________
ioNiNJA
o_dog is offline   Reply With Quote
Old 07-25-2011, 10:37 PM   #79
Yil
Too much time...
FlashFXP Beta Tester
ioFTPD Administrator
 
Join Date: May 2005
Posts: 1,194
Default v7.7.3 Changelog

Code:
v7.7.3 Release Notes:

1) Files in \System:
   Changed : ioFTPD.[exe,pdb] - Version 7.7.3.0
   Changed : ioFTPD.ini - summary of changes by section...
     [FTP_SITE_Permissions] : ciphers           =     M
     [Ftp]                  : Show_HostMask_Error      = True


2) Changed the default configuration for 'Show_HostMask_Error' in the .ini
   file to True, and explicitly stated the Cipher command permissions.


*** Bug Fixes

3) Fixed a bug in the internal resolver that was improperly resolving paths
   involving NTFS junctions/symlinked directories when NTFS_Reparse_Method
   was either SHARED or SYMLINK.

4) Fixed two bugs when trying to delete a NTFS junction/symlink via the file
   DELE command when NTFS_Reparse_Method was set to SYMLINK.  The first one
   didn't account for the fact that SYMLINK mode should work on directories
   that are shown as symlinks, and the second didn't remove the NTFS junction
   or symlink before attempting to delete the directory so it would only
   delete empty dirs.

5) Fixed a bug where files created or deleted from a directory didn't mark
   the cached parent directory as stale which meant that the parent wouldn't
   show the size of the subdir correctly.  This bug was masked by the fact
   that most zipscripts touched or modified the directory in some way and
   that forced an update.

6) Fixed a bug where unkillable zombie connections could be created if a data
   connection was arranged but the connection had not been established and the
   control connection was closed via a kick/kill or the client closed it.
   What was particularly annoying about these zombie connections is that
   you couldn't get rid of them until the FTP was restarted.

   NOTE: There are still 2 known ways to create zombies.
   a) An idle control connection where the user machine bluescreens, looses
      power, or has a network interruption.  In this case TCP/IP on the client
      cannot inform the server that the client closed the connection.  These
      clients can be kick/killed at anytime, and TCP KEEPALIVES could be
      enabled on the machine to test the connection every few hours if this
      ever becomes an issue.  These are not a problem.
   b) TCL scripts that never return are not currently handled.  EXEC scripts
      have for a while checked to make sure they aren't zombies, but TCL
      scripts can create an unkillable zombie.  There is an interface to let
      TCL check status after a certain number of commands or after a timeout
      has expired but I'm not using it because it won't handle all situations
      and this hasn't been a big problem.
Yil is offline   Reply With Quote
Old 07-25-2011, 10:50 PM   #80
Yil
Too much time...
FlashFXP Beta Tester
ioFTPD Administrator
 
Join Date: May 2005
Posts: 1,194
Default

Source for 7.7.3 posted as well. I meant to do this a while ago once it looked like things were stable...
Yil is offline   Reply With Quote
Old 07-27-2011, 03:55 PM   #81
paja1
Member
ioFTPD Registered User
 
Join Date: Jul 2005
Posts: 43
Thumbs up

Hi Yil,
i just founded another strange behavior. One folder is "invisible" for ioFTPD.
VFS file is still the same like in version v6.6.0 (where all worked fine), but now with version 7.7.3 i'm getting only "No such file or directory." Is there any limitation of number of folders/files?

Btw, i have about 1200 sub-folders in that folder.

Is there any way "debug" why it's not "accessible"?

Thx
Pavel


SOLVED: there was an errors on NTFS level. Sorry guys.

Last edited by paja1; 08-12-2011 at 01:56 AM.
paja1 is offline   Reply With Quote
Old 07-27-2011, 03:56 PM   #82
o_dog
Senior Member
 
Join Date: May 2007
Posts: 692
Default

does the folder contain strange characters?
__________________
ioNiNJA
o_dog is offline   Reply With Quote
Old 07-28-2011, 08:02 AM   #83
Yil
Too much time...
FlashFXP Beta Tester
ioFTPD Administrator
 
Join Date: May 2005
Posts: 1,194
Default

There isn't any current limitation in the number of subdirs so that shouldn't be a problem. Can you see it in the parent's directory listing but not enter it? In that case my guess would be similar to o_dog's, check if there any special characters in the name if you look at it in window's explorer? If you can't see the subdir from its parent then it could still be a weird character, but it could also be a number of other things including being a NTFS hidden/system dir, an ioFTPD hidden dir (unless you're a VM flagged user), etc.

If you were to zip/rar the dir and extract it somewhere else does the FTP show it? If you manually delete the .ioFTPD* files from the copy does that change anything (use 'site refresh' to force cache of parent and dir itself to get new copies)? If it's still missing then delete the big files from the dir, zip/rar the nfo/sfv/etc and I'll look at it.
Yil is offline   Reply With Quote
Old 07-28-2011, 05:54 PM   #84
o_dog
Senior Member
 
Join Date: May 2007
Posts: 692
Default

YiL: how about adding a custom filed or three to the userfiles? =)
Would like a nice way of storing custom individual information, like settings for xdupe
__________________
ioNiNJA
o_dog is offline   Reply With Quote
Old 07-28-2011, 07:24 PM   #85
Yil
Too much time...
FlashFXP Beta Tester
ioFTPD Administrator
 
Join Date: May 2005
Posts: 1,194
Default

o_dog: You mean something like the "opaque" field in the userfile? 255 bytes of whatever you want designed for script use - just make sure there isn't a return char in there as the line break would probably break the stupid userfile parser... I suggested scripts store trivial things in there using TCL style quoting and use a <name> <value> pair setup so multiple scripts could get along with each other. I was personally thinking of using [array get/set]. This field can also be modified via 'site change opaque'.

I read the ninja thread first and mentioned how you can get your x-dupe to easily override the one coming in v8. I wasn't sure if I was going to preserve the x-dupe level across logins though so at the moment it doesn't even try and users would need to add it to the list of commands to enter after connecting.

I'd love a bunch of new fields to the userfile for things like banned time/reason, etc but I'm really trying to avoid that because that means updating nxMyDB as well. I think we need a few more fields so I can do a whole bunch at once. Please feel free to chip in whatever fields you think we might need in the future. I would love dynamically created fields, but that would totally break nxMyDB and it's easy enough to use SQLite or a simple text file to store stuff.

On a related note, I've played with storing the CRC32 value for each file in the .ioFTPD file (there's 4 bytes left free to do so) so you can enable a .ini option to make the server compute the CRC32 value of downloaded files and compare it after the file is sent, sort of like drFTPD does as an added check. The TCL interface to record the CRC32 value isn't implemented yet but it should be trivial to just pass the value already passed to the script for upload events, or re-compute with the existing TCL CRC32 function it you modify the file and need its new value.
Yil is offline   Reply With Quote
Old 07-28-2011, 07:49 PM   #86
o_dog
Senior Member
 
Join Date: May 2007
Posts: 692
Default

well, storing them might be a good idea so you get them on resolve list. Only thing it would be really good for as far as i can see is rescan though, or if a sfv file is being uploaded after files, i store them in the .ioftpd file now. As for comaprison of downloaded files, i have no idea what good it would do since most things have to be handled on other side of the connection.

for tcl storing the crc values or updating it rather? it's needed for rescan purposes. link the [crc32] to update the field for the file, otherwise things might not turn out all that well. This is really needed before rolling it out since it might mess things up for people.

My main problem right now is that i moved away from locks to stats using [resolve list ...]
This however does not contain information for the file being uploaded, it's all zeros. Might be a good idea since otherwise it would present a problem with people seeing filesize but not being able to access the file before the script release it. But some way of getting the info in same format for the file uploaded as [resolve list ...] would be nice.

Downloading of partially uploaded files would be nice too. Didn't like it before but starting to warm up to the idea.

As for nxdb:
Was actually thinking of finishing the script i was writing for syncing the user dbs through a mysql db. This is really a better way of doing it in my experince, since nothing at all is dependent on a module, and each site operates totally indivdual. I actuallly think the script i wrote works. It just copies the userfiles/groupfiles to a mysql db and sync fileds over sites that are connected. can transfer credits with a 20s delay or something which is something people would have to live with. It also stores stats for the individual sites.
How well it works at the moment is hard to say since i never used it on any larger scale. I don't even know what the interst of something like that would be.
__________________
ioNiNJA

Last edited by o_dog; 07-28-2011 at 08:03 PM.
o_dog is offline   Reply With Quote
Old 07-28-2011, 07:51 PM   #87
o_dog
Senior Member
 
Join Date: May 2007
Posts: 692
Default

Btw we should really get a site for the scripts and ioftpd rather than this obscure forum =)
__________________
ioNiNJA

Last edited by o_dog; 07-28-2011 at 08:05 PM.
o_dog is offline   Reply With Quote
Old 07-28-2011, 07:53 PM   #88
o_dog
Senior Member
 
Join Date: May 2007
Posts: 692
Default

I was also thinking of adding md5 check for things, might add this as a separete script though since it's a better way of checking fileintegrity but without a single damn rule about how it's done it's a pain to write any kind of script for it.
__________________
ioNiNJA

Last edited by o_dog; 07-28-2011 at 08:05 PM.
o_dog is offline   Reply With Quote
Old 07-28-2011, 08:53 PM   #89
Yil
Too much time...
FlashFXP Beta Tester
ioFTPD Administrator
 
Join Date: May 2005
Posts: 1,194
Default

Isn't [resolve list] really useful? My first attempt at ioYil duplicated that functionality entirely in TCL and it was rather annoying getting all the mountpoints right, finding all entries across merged filesystems and making sure the first found controlled the permissions, etc. It worked but was slow and prone to eventually diverging from how the internal resolver worked...

If you intend to work on your userfile tool let me know if there's something that would make your life easier. I've got a list of "optimizations" on my TO-DO list that I've been adding to for a while that could increase the server speed substantially and one of those was to provide a hint field to the userfile module which would indicate what portion of the userfile was updated. That may not mean anything if you just copy all the fields every time or deal with the complete file itself, but the vast majority of the time only the stat/credit fields are updated and thus there is no need to check/update the normally static portions of the userfile. This would help the server itself skip checks for hostmask changes, etc which trigger internal updates but it would also mean things like nxMyDB wouldn't have to do that either. This will necessitate changing the dll user module interface in one or two places as well... The other "feature" this would enable would be logging userfile changes to a new logfile which would have a simple 1 line entry for file up/down stat/credit changes and another for full check needed. The idea here would be a new ioGUI replacement would have up-to-date userfile data by just applying the changes from the logfile as they appear so you wouldn't have a reload userfiles button or something like that or have to scan all the userfiles all the time. However, you could just read the stream and apply the changes locally and forward them to another site if you wanted... If you think that would help let me know and I'll take a 2nd look at the idea.
Yil is offline   Reply With Quote
Old 07-28-2011, 09:07 PM   #90
Yil
Too much time...
FlashFXP Beta Tester
ioFTPD Administrator
 
Join Date: May 2005
Posts: 1,194
Default

Oh, the downloading of partial files idea... I mentioned that list of optimizations, and one of them includes a number of tweaks to how and when things are done in the file transfer engine. I have a pretty good idea of what I'd like to do to make it go faster but when I re-wrote a lot of that to switch over to OpenSSL I didn't want to introduce anything that was too complex in case it broke lots of things... I did however keep the idea of downloading an active upload in mind, since a couple of people wanted it as an option, and it wouldn't be trivial but I can think of one or two ways it might be done. It won't be anytime soon though...

Some things that might come sooner would be smaller things like an option to bypass using the windows file cache for files being downloaded. I think this might be useful since right now files downloaded go into the file cache like everything on the machine normally does, but this ends up pushing newly uploaded files out sooner than I'd like. If most of the time you end up downloading files that were just uploaded this could be a performance win especially since it's far more likely that a newly uploaded file would be downloaded more than once so it's best if it stays in the windows file cache. It's important to point out that this is windows file caching in extra unused memory on the machine, the actual memory footprint of ioFTPD itself wouldn't change at all. Obviously this would help systems with lots of memory much more.
Yil is offline   Reply With Quote
Reply

Tags
bug, code, directory, release, user

Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -5. The time now is 12:39 PM.

Parts of this site powered by vBulletin Mods & Addons from DragonByte Technologies Ltd. (Details)