Quote:
Originally Posted by Yil
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
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
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
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.
iTCL extensions
Linear Mode
