Old 05-19-2008, 12:15 AM   #1
Yil
Too much time...
FlashFXP Beta Tester
ioFTPD Administrator
 
Join Date: May 2005
Posts: 1,194
Default iTCL extensions

If the only access to information was through ioFTPD itself what features should iTCL provide? In particular, I see the new symlink resolving code is a nice addition, but if you had to do that without parsing the vfs files and instead called a new function what should it look like? I believe based on earlier research that ioFTPD never reverses a physical path back to a VFS path internally. So I'm assuming a script probably doesn't need to do so either, but if you do let me know and is it avoidable somehow?

Consider also that raided/merged directories will probably be much more common in the future when the disk spanning stuff gets introduced. Right now the resolve function can only return a single value and to not break everything immediately I'll probably end up adding a new resolver function with a different name that can return a list. Based upon my sidelined code for disk spanning it tried to keep all files in a single directory but subdirs could be on different disks. Thus xyz/cd1 and xyz/cd2 could be separated which means when looking at the directory and enumerating subdirs in the future it will likely be necessary to do that to all returned values from the new resolver function and merge the results.

The alternative is I've been looking at the TCL virtual filesystem interface which is much better in the new TCL releases. It looks possible that I could build an ioFTPD filesystem so that all normal TCL commands would operate on ioFTPD VFS paths and there would be no need to know the actual physical location of anything anymore! Paths would look like "ioFTPD:/VFS-PATH". How cool would that be? Would that be a good thing and if not why?

How about a sections iTCL extension for querying section information so you don't have to parse the .ini file? What info do you need? Propose an interface and I'll see what I can do

I've been adding features based on what I want in the server, but I'm happy to add features that directly support scripts especially if they remove dependencies on ioFTPD config files. This is also somewhat important since I've considered going to XML or something so that the config file is more robust. Of course that means I need to get scripts away from reading it...
Yil is offline   Reply With Quote
Old 05-19-2008, 02:50 PM   #2
neoxed
Too much time...
FlashFXP Beta Tester
ioFTPD Scripter
 
Join Date: May 2003
Posts: 1,326
Default

Quote:
Originally Posted by Yil View Post
If the only access to information was through ioFTPD itself what features should iTCL provide? In particular, I see the new symlink resolving code is a nice addition, but if you had to do that without parsing the vfs files and instead called a new function what should it look like? I believe based on earlier research that ioFTPD never reverses a physical path back to a VFS path internally. So I'm assuming a script probably doesn't need to do so either, but if you do let me know and is it avoidable somehow?
nxTools requires a method of resolving symlinks within a virtual path. For example:

- An FTP client issued the command "MKD /Today-MP3/Stuff"
- ioFTPD would tell nxTools of the event via [FTP_Pre-Command_Events] and FTP_Post-Command_Events
- When nxTools goes to insert the directory into the dupe database, it has the path "/Today-MP3/Stuff" instead of the proper expanded form of "/MP3/0518/Stuff".

After receiving more and more complaints from users I finally added a hack to work around it. I wanted to avoid parsing VFS files as well, but it seemed to be the only quick solution.

I am slowly working on a ground-up rewrite of nxTools and I was hoping to properly address this issue in the re-write. I was planning on taking a more solid look at ioFTPD's code to see if there was a more elegant solution but I haven't had time yet.

Quote:
Originally Posted by Yil View Post
Consider also that raided/merged directories will probably be much more common in the future when the disk spanning stuff gets introduced. Right now the resolve function can only return a single value and to not break everything immediately I'll probably end up adding a new resolver function with a different name that can return a list. Based upon my sidelined code for disk spanning it tried to keep all files in a single directory but subdirs could be on different disks. Thus xyz/cd1 and xyz/cd2 could be separated which means when looking at the directory and enumerating subdirs in the future it will likely be necessary to do that to all returned values from the new resolver function and merge the results.
Personally, I've always found the "merged directory" support to be a mis-feature. The idea of it is great, but in practice it poses several challenges to scripts interfacing with ioFTPD. I would rather leave features like this to the underlying file-system, since NTFS supports dynamic spanned disks at the FS level.

If you are planning on polishing the "merged directory" feature, my only request would be to add some better APIs for path resolving.

Quote:
Originally Posted by Yil View Post
The alternative is I've been looking at the TCL virtual filesystem interface which is much better in the new TCL releases. It looks possible that I could build an ioFTPD filesystem so that all normal TCL commands would operate on ioFTPD VFS paths and there would be no need to know the actual physical location of anything anymore! Paths would look like "ioFTPD:/VFS-PATH". How cool would that be? Would that be a good thing and if not why?
The TclVFS extension would be a very interesting approach, however, I think some scripts will always require physical location of the files for external applications. For example, there is a script that calls MediaInfo.exe with the physical path to extract information about audio/video files.

Quote:
Originally Posted by Yil View Post
How about a sections iTCL extension for querying section information so you don't have to parse the .ini file? What info do you need? Propose an interface and I'll see what I can do
That would be very useful, as that is the only reason nxTools parses ioFTPD.ini. If the config command offered a way to list the available INI sections and INI keys, there would be no need to read the ioFTPD.ini.

config keys <section> - Returns a list of all keys within an INI section
config sections - Returns a list of all INI sections

Code:
foreach key [config keys "Network"] {
    set value [config read "Network" $key]
    iputs "\"$key\" is set to \"$value\""
}

would output:

"Active_Services" is set to "FTP_Local FTP_NAT"
"Ident_Timeout" is set to "0"
"Hostname_Cache_Duration" is set to "1800"
"Ident_Cache_Duration" is set to "120"
"Internal_Transfer_Buffer" is set to "65536"
"Scheduler_Update_Speed" is set to "NORMAL"
"Connections_To_Ban" is set to "30"
"Ban_Counter_Reset_Interval" is set to "120"
"Temporary_Ban_Duration" is set to "300"
Those two additions to the config command would remove nxTools' dependence on reading the INI file manually.

PS: I'm really really hungover right now, so hopefully my reply is readable.
neoxed is offline   Reply With Quote
Old 05-19-2008, 07:17 PM   #3
Yil
Too much time...
FlashFXP Beta Tester
ioFTPD Administrator
 
Join Date: May 2005
Posts: 1,194
Default

Totally readable!

VFS normalize path. Check, I'll add that.

NTFS dynamic disk spanning I admit would make script writing easier! I don't think dynamic disks are offered in the Home versions of XP. Not sure about Vista Home but wouldn't surprise me if it's not available there either. So that's a pretty big issue... Also, backup/restore from them is trickier, and well, if you loose a disk it's a nightmare.

Physical paths. Actually a command to turn a VFS path into a physical path I agree will always be necessary for FILES. 3rd party executables to get stuff like MP3 info, etc will often be necessary. It's enumerating the contents of directories or thinking their is only 1 path for a directory that will be the issue. Which is why I'm thinking I should either make a new iTCL command to return the files/dirs in a directory that matches the semantics of the regular TCL command, or try the virtual filesystem thing

Config iTCL command... Check, I can add that. In fact there is already the "site config" command which allows you to actually EDIT the .ini file on the fly and rehash it and read the contents. Probably should add an override option in the .ini file itself to disable site config and this new iTCL command from editing the config file though...
Yil is offline   Reply With Quote
Old 05-19-2008, 07:26 PM   #4
Yil
Too much time...
FlashFXP Beta Tester
ioFTPD Administrator
 
Join Date: May 2005
Posts: 1,194
Default

Oh, one other nice addition. v6.5 restarts the TCL interpreter for a thread the next time a TCL command is called after a site rehash now. So now you don't have to worry about going fast or reloading the config file each time to catch new settings. This should be the best of both worlds...
Yil is offline   Reply With Quote
Reply

Tags
files, function, ioftpd, itcl, vfs

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 Off
HTML code is Off

Forum Jump


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

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