ioFTPD v7.0.3 Released - Page 8

dr.owned · 10-07-2009, 06:42 AM

is there a reason why i can't specify an arbitrary-depth mountpoint? for now i either have to create full path of empty directories from a root directory or have one empty directory mounted several times once for each directory in a path.
being able to write:

Code:

"d:\ftproot"	/
"d:\data\dummy"	/dir
"d:\data\distr"	/dir/subdir/distr
"d:\data\music"	/dir/subdir/music

in vfs file without having actual "subdir" directory anywhere but inside this the vfs file would be nice.
and also having a function call:

Code:

[resolve Mount "/dir"]

return

Code:

/dir
/dir/subdir/distr
/dir/subdir/music

instead of just

Code:

/dir

as it does now. since all three intries are surely [quote from documentation] associated with that path [/quote]

and yes, all my questions and requests are driven by the need of solving existing problems and are not just obscure geeky flood

dr.owned · 10-07-2009, 09:03 AM

hmm.. it looks like i can't set a virtual directory as a home directory. instead of using directory contents generated by script server seem to expect ||resolved|| link. and i can't return a link pointing at virtual directory itself as in this case server just defaults to root directory. the only time i can somehow get it to work is when i return ||resolved|| link pointing at another non-virtual directory. but server then just CWDs into it and ceases script calls as it is already out of virtual directory.
i think it's worth fixing.

SysOp · 10-07-2009, 10:01 AM

I think I've found a bug in ioFTPD-v7.0.0-src, and I don't know whether it's fixed or not. Anyway, that's it:
In .\src\Identify.c, line 1029, before "AddClientJob(..., 10005, ... lpAcceptProc ...)", there should be an additional line like this:

Code:

pConnection->szIdent = NULL;

If not, when Ident_Timeout=0, in log files, users' Ident will be 4-byte random characters instead of "*".

p.s. Where can I find the newest source file? for example, v7.0.3. Are they accessible to public?

ArtX · 10-07-2009, 10:04 AM

Quote:

Originally Posted by SysOp

p.s. Where can I find the newest source file? for example, v7.0.3. Are they accessible to public?

Normally there are yes,Yil puts the source out with the release, but his ISP was having issues so maybe he just uploaded 7.0.3 to this server, im sure he will put a link up to 7.0.3 source in due time

7.0.2 source is in this thread somewhere

pion · 10-07-2009, 01:54 PM

Why not put up a repository at google code or similar?

Yil · 10-07-2009, 05:44 PM

dr.owned: A specifiable ban time with optional reset feature and the ability to add/remove entries via script. Will do.

You must, however, have a valid real directory tree from root for all paths in the regular VFS. There doesn't seem to be a good reason to break that behavior especially with the future option of reverse resolving paths. On the other hand the hidden/special directory option might make it look that way to a client.

[vfs mount] should return virtual mountpoints in the current directory provided they are accessible. In your example they aren't because of the missing parent...

SysOp: Yup, that's a new bug introduced with v7.0 if you use the new feature to disable ident requests entirely! Gold star

I think that's the first fixed bug by anyone but me in the code in years! I'll look into keeping an up to date copy of the code somewhere so you can always get the latest stuff. Previously I just released the 6.X or 7.X releases as nobody really bothered with it except for perhaps FtpServerTools...

dr.owned · 10-07-2009, 08:46 PM

Yil

once again, big thanks. can't wait for the new release.

and don't forget to fix home directories declared as virtual. generated directory contents must work.

dr.owned · 10-09-2009, 11:09 PM

oh man, i finally persuaded ioftpd to handle virtual home directory right and managed to lock user inside it for good

i wish i had a more convenient way to do it

pion · 10-10-2009, 05:39 AM

I had a weird problem with ioFTPD 6-4-3r that I don't think have been adressed in io 7. Or it could be related to lockup bug. For some reason all pasv ports where locked out! ioftpd.exe had been running with working pasv connection for a good while, control connection was fine, and port mode was working, but all of a sudden all pasv requests went to timeout. There is no firewall or router of any kind running, nor any antivirus or similar. Once I restarted the ioftpd.exe process, the pasv ports where reacting like normal.

I have no clue on how to reproduce it, or why it happened in the first place..

My question is if this bug has been discovered, and fixed with io7 or if it's still there?

I may add that this server has been severly affected by the lockup bug before, and initial tests of io7 on it seems to be stable!

Yil · 10-11-2009, 01:00 AM

pion: That 6.4.3 issue sounds like the lockup bug, but without trying to exit the server and having the process hang around I can't say for sure. I changed the way child processes are created and tried to protect all sockets from being inherited in v7. So far several people have reported it's much more stable so I think that's part of the problem. Some people had a terrible time running under w2k3 which seemed to trigger the bug fairly frequently now have respectable uptimes.

I missed protecting the server from the TCL library as it does create sockets as well. So I'm guessing it's only 99% fixed if people are running imdb style lookup scripts as they create TCP connections and for a very very brief window new executable child processes might trigger the problem.

dr.owned · 10-11-2009, 11:10 AM

is there a more convenient (and efficient) way to retrieve full list of directory entries for a given VFS path $mnt than using [resolve Mount $mnt] and cycling through each element with [glob -type f $realPath] and [glob -type d $realPath]?

Yil · 10-11-2009, 07:56 PM

dr.owned: Nope, that's the "new" way to do it actually since [resolve mount] is a very new command (I haven't even had a chance to play with using it in my own scripts). Most existing TCL scripts just use [resolve pwd] and thus can't handled merged/raided directories.

On the other hand I've added the [vfs dir] command (and again haven't used it myself yet) which you can use to determine if a directory is a symbolic link and/or get the owner of the file/directory. If you need either of those two pieces of information then this may be more efficient than globbing and then individually testing the entries. I'm pretty sure nobody else is using this command yet so it's possible to change the output to include the directory attributes information (which you can use to test for dir/file/junction/etc) as that looks like it would be really useful to have. I'm also thinking of what to do with attribute #1 for symbolic links when dealing with NTFS junctions, etc since they will be treated as links but they aren't ioFTPD links so I'll either modify this command or create a new version of it that's a bit more useful...

FYI: Internally lots of things are done with real paths. Thus even the [vfs dir] feature still operates on a single real path and you will need to cycle over the [resolve mount] output or the proposed simpler [resolve pwds] command.

I ended up writing a whole lot of resolving logic for ioYil and started to run into the problems you are seeing. So I stepped back and took what I found to be duplicating internal server logic and started exposing the server's routines as exported TCL functions instead. If you look back at the changelog you can see this trend.

I'm not adverse to try to fake out the directory listing routines to generate a VFS directory entry with detailed information so you could avoid globbing and asking the server for info entirely. I can see why that would be useful but I haven't yet needed it because there is a subtle issue when dealing with writing something like nxTools. Since the server deals with real directories it's possible for 2 different mountfiles to mount 2 or more real directories in a different order onto the same mountpoint. This means that the actual permission/ownership information varies with the active mountfile. I even wrote some logic to warn users when this was occurring just to make sure it was intentionally done, but it also meant that I didn't really want everything resolved via VFS path and instead stored entries in the DB by real path and then did the merging logic myself to handle these edge cases...

But, like I said, I don't see why I can't return all the info that is visible in a directory listings to you and let you deal with those complexities for a particular user's view of the filesystem.

dr.owned · 10-11-2009, 09:54 PM

Yil
yeah, i checked out [vfs dir] as well but it returned too little information so you event couldn't tell files from directories. and i ended up globing. so i welcome your suggestion to extend that function. i'll be glad to also see file sizes and creation\mod dates in the output (to fit AddFile syntax). and especially glad if it would involve some caching to speed up frequent calls. because now [glob], [file size] and [file mtime] calls take mindblowingly much time.

+ is it a feature that data connection is assigned the same ip address as the control connection that spawned it (when viewed from ioGui)? i'm asking because i'm now using FTProxy to help me where ioftpd+tcl is not enough. and it masks real ip address from ioftpd. but when i turned off data connection relaying i expected to see real ip in ioGui for file transfers. but to my surprise ip address stayed the same.
come to think of it, the ip address logged to xferlog must be the one that connects to ftp server and actually gets data (or the one that ftp server connects to on PORT command) and not the one that said RETR. i understand that i'm digging too deep and in 99.99% cases people don't care about such tiny aspects. but still, for the sake of being absolutely correct...

dr.owned · 10-11-2009, 10:09 PM

i also noticed that sometimes ioftpd outputs something like this:

426 Connection closed: xxxxxxxxx xxxxxxx xxx xxxxx xxxxxxxxxx.

yes x-es instead of message. i believe that it is a winsock error messge that ioftpd failed to output correctly on a non-english system (which is my case).

pion · 10-15-2009, 07:16 AM

Does io 7.03 support reading a file in use? (EG. being uploaded)