ioFTPD v7.0.3 Released - Page 5

Yil · 09-29-2009, 07:03 PM

paja1: Woohoo someone playing with pure virtual dirs. I PM'd you info on where to upload the crashdumps. If you have some simple test cases that show the problem I'll be happy to try those out locally and/or see what I can make from the dumpfiles. I tested the simpler 1 and 2 level deep cases since I had scripts around I could modify to play with. But it looks like something isn't happy when things get deeper.

Yil · 09-30-2009, 02:13 PM

Paja1: I've diagnosed the problem from the minidumps you sent me. I improperly allocated the size of an internal virtual info array by forgetting to multiply the number of elements by the size. If you can test the rest of the functionality by only using 25 or so entries per directory things should become stable again until I can get v7.1 out with the fix for larger dirs.

Dahlia · 09-30-2009, 03:50 PM

Yil please,
i read in your To-Do list that you want to add option to change:

SITE UTIME support (1 arg version?)
SITE ATIME/PTIME support (alternate-time) setting for dirs

i hope this is what im looking for. because is very annoying to have on server with ioftpd always +1(or 2h) server time than is my real time in my time-zone.

for example:
im in european UTC (CET) +1 zone. if i have real server time and if i make dir with ioftpd the dir has always wrong time (-2h). if i want to have correct time on dirs i need to change my server time to +2h (now in summer). but with this option i wont use for example script like Topstats (i run that script everyday at 23:55) because topstats is reading ioftpd.log and xferlog and those files have correct server time (not like dirs made by ioftpd) and this script at 23:55 give me only stats (created/deleted dirs, etc,...) from 1h and 55minutes from next day. i hope you understand what i mean :X

it takes so much time or is it possible to add that TIME option (something like SET your TIMEZONE: CET +1) already to io7.1 version ?

thank you

paja1 · 09-30-2009, 04:54 PM

Quote:

Originally Posted by Yil

Paja1: I've diagnosed the problem from the minidumps you sent me. I improperly allocated the size of an internal virtual info array by forgetting to multiply the number of elements by the size. If you can test the rest of the functionality by only using 25 or so entries per directory things should become stable again until I can get v7.1 out with the fix for larger dirs.

Hi Yil,
thank you for a good news.. i'll try and play with it but under restriction of max. 25 items in one fodler. Btw, i do have troubles with caching, when i enter SubDir script is invoked but in FlashFXP i can see content from parent folder. When i press F5 to refreh the content i can see proper one. The same situation if you are going back, one level up.

To the stability of 7.0.1, i;ve discovered another unstable moment, if you have folder with a lot of gigs and try to rescan crc or call any long, long running script.. you will lost connection, which is the same behoviour like in 6.x.x, but daemon dies.. which is new and quite unpleasant. Can you please check it out?

Thanks!

Yil · 09-30-2009, 06:28 PM

dahlia: All times in the server are in UTC time. Have you tried setting the timezone for the server in your FTP client? I think that's probably a simpler solution. If you've tried that what still doesn't work?

paja1: Hmm, not sure on the caching issue. Try disabling caching in the client for the site and see if that makes a difference. If so take a look at the return values and see what's going on. I do know FlashFXP cwd's and then does a pwd to figure out where the server ended up to check if it already has it in the local cache. Perhaps I'm returning the wrong directory name after a change for directories more than 1 or 2 layers deep in a virtual dir...

Long running scripts. Is this a tcl or an exec script? I totally rewrote the whole exec scripts module to prevent the v6 timing out behavior and ran a number of test cases on the changes but maybe I missed something... Which script did this and if you have minidumps send them over and I'll get that fixed for ya.

paja1 · 10-01-2009, 04:32 AM

Quote:

Originally Posted by Yil

paja1: Hmm, not sure on the caching issue. Try disabling caching in the client for the site and see if that makes a difference. If so take a look at the return values and see what's going on. I do know FlashFXP cwd's and then does a pwd to figure out where the server ended up to check if it already has it in the local cache. Perhaps I'm returning the wrong directory name after a change for directories more than 1 or 2 layers deep in a virtual dir...

Ok, will try to play with it a bit, and also will try to compare comunication as in 'normal' folders everything works just great.

Quote:

Originally Posted by Yil

Long running scripts. Is this a tcl or an exec script? I totally rewrote the whole exec scripts module to prevent the v6 timing out behavior and ran a number of test cases on the changes but maybe I missed something... Which script did this and if you have minidumps send them over and I'll get that fixed for ya.

It's definately exe, and its zip script for checking consistancy, ioZS but not the latests version. On 6.x it's working fine. On 7.0.1 it crashes quite often, on timeout everytime.

I'll try to get some crash dump or you.

Br,
Pavel

Dahlia · 10-01-2009, 09:52 AM

Quote:

Originally Posted by Yil

dahlia: All times in the server are in UTC time. Have you tried setting the timezone for the server in your FTP client? I think that's probably a simpler solution. If you've tried that what still doesn't work?

I tried to set TimeZone in my ftp client (FTPRush)

1. "Casablanca/Monrovia timezone" is the only one timezone that give me the correct date of created dir - but i'm in GMT +1 timezone
2. It's almost impossible to say to every single user -> "set your timezone in your ftp client to 'something what is not even your timezone'"

and here is normal setting in ftpclient (-2h of created dir/file)

I think everyone who is in some different timezone than UTC must have the same problem.

The only one problem is incorrect date/time of created dirs/files. Every single log message in ioftpd is correct 'with current real server time'. Some internal script for change date/time of created files might help but dunno how much will that script slowdown the writing process.

thank you for answer

razoor · 10-01-2009, 08:13 PM

i have mentioned the UTC before in ioFTPD since i want it to be changed to.

https://oss.azurewebsites.net/forum/showthread.php?t=12503

paja1 · 10-02-2009, 09:09 AM

Yil, i'm playing with ioVirtual for a while already and i have to say:
*I LOVE* your implementation of Virtual FS!!!!
It's soooo powerfull .. thank you, thank you!!!!

Just please fix that 25 items limitation and problem with cashing... and we are ready to go!

Yil · 10-02-2009, 06:49 PM

New Version:
ioFTPD-v7.0.2.zip

Code:

v7.0.2 Release Notes:

1) Files in \System:
   Changed : ioFTPD.[exe,pdb] - Version 7.0.2.0.
   Changed : ioFTPD.ini - summary of changes by section...
     [Themes]           : Theme #4 should say Light-Min instead of Light-Max


*** Bug Fixes:

2) Fixed a bug in the EXEC module that improperly manipulated the input buffer
   and would crash the server when the undocumented redirect commands such as
   !vfs:add were used by scripts such as ioZS.  Redirect commands allow EXEC
   scripts to ask the server to perform operations.  These command lines are
   stripped from the output before it's sent to the user.  For the record the
   full list of redirect commands are: !putlog, !vfs:add, !vfs:chattr,
   !change, !unlock, !newlines, !prefix, !buffer, and !detach.

3) Fixed a bug in InsertVirtualInfo that failed to allocate enough space
   for the VirtualInfo array.

4) Fixed a bug in "site ioverify".  The faked out user/group databases used
   to verify accounts were being freed twice because of a bugfix in v7 that
   started to properly cleaned up memory during shutdown.

5) Fixed a bug in %[IF] which would improperly evaluate to true if the
   comparison string was a prefix of the input string.

6) Fixed a bug that would output an incorrect error message on non-english
   systems.  Lines would look like:
     426 Connection closed: The system cannot find message text for message
     number 0x%1 in the message file for %2.

7) Fixed a type in ioFTPD.ini where theme #4 was labeled Light-Max instead
   of Light-Min.  Start of new line should look like "4 = + 2 Light-Min ..."

8) Fixed a race condition in directory PreLoading during startup that may have
   been causing the crashes.

Yil · 10-02-2009, 06:54 PM

Timestamps in ioFTPD. Are you changing the timezone setting for the site in FlashFXP,etc to YOUR timezone or to UTC? That setting is for the timezone the server is in. If I set it to UTC all the times look fine for me for newly created items.

Also, be careful about the latest version's of FlashFXP's automatic timezone discovery mechanism. It will choose files that are old enough that they would show up as Oct 2 2007 instead of a current Oct 2 16:40 format and totally screw up the time offset...

Yil · 10-02-2009, 08:08 PM

I forgot to include this in the Changelog when first posted...

Code:

8) Fixed a race condition in directory PreLoading during startup that may have
   been causing the crashes.

paja1 · 10-03-2009, 03:33 AM

Yil, one word: THANK YOU!
(was actually two

)

Btw, what about Virtual Folders caching/refreshing 'problem'?

dr.owned · 10-03-2009, 12:35 PM

hi.
i've been using ioftpd for quite some time. scripting support kicks a$$, and finally there is a feature i've been lookin for so long - virtual dirs.
after some tests i discovered the following things i look forward to be fixed\explained:
- not really an issue but still: with only one mount point present - root mount point - virtual directory just doesn't work. cwd tells no such file or directory.
- commands like AddFile and AddLink create links to target files which are displayed along with faked filenames when viewed from a ftp-capable web browser ("file.ext -> /original_mount/file.ext") and hence couldn't be downloaded. i wonder if it will be fixed or become configurable (like HideVirtualSymlinks = TRUE/FALSE). i guess server can show ordinary filenames in listing while preserving linkage info internally.
- this one might be a noob question but how do you make the server give you a file requested with a full path from a virtual directory while working dir is root?
CWD /
RETR /virtual_dir/subdir/filename.ext
what scripts should i write and where do i put them?

thanks in advance.

Yil · 10-03-2009, 04:33 PM

dr.owned: Hmm, I'm not aware on any reason why just having a root mount point would prevent virtual directories from working but that should be easy to test. I can point out that v6 style virtual directories requires a real directory or mountpoint in the location of the virtual mountpoint and v7 requires there to NOT be a real directory in that location. Make sure you don't have a /search or a /latest, etc directory.

Hmm, interesting tidbit on FTP capable web browsers not understanding symbolic links. I was under the impression that they just ignore the link part and everything works fine since I'm pretty sure I've traversed links in FireFox on FTP connections before... You can use AddDir/AddFile with "" specified for the LINK field and the listing will show up without a link (see doc/itcl.txt). However, the server has no idea what the heck that entry is so when accessed it will act like AddSubDir would and call the script to resolve the link at which point you return a ||RESOLVED|| type result. That is obviously more expensive but should act as a workaround right now. I'll have to see about a special LINK syntax like a leading : or something that would keep the linkage internally but not show it...

Full path syntax to virtual files. You just need to return the ||RESOLVED|| result from your script because the request resolved to an item and not a virtual directory listing. That should work.