Quote:
Originally Posted by Yil
dr.owned: Can you give me some examples of why knowing the command being run makes a difference as to what the script should return?
|
that's really easy. say i'm renaming or deleting a subdir in a virtual directory. the sciprt is only aware of that he should process "/virtual/subdir", so it looks at the specified path, determines it's a directory and returns its listing. but instead it should have returned ||resolve||-d link to it. there a no means by which the script should know what to do (only with a workaround i mentioned before).
or another example - to fake responses to commands like MDTM, RETR... or reversively, to make responses more ftp-client-understandable. because "modifying virtual directories is not allowed" isn't exactly what ftp clients expect when they commit something they can't.
and when RETR-ing, it would be nice to know whether it starts from byte 0 or a REST 123123 command was issued earlier and the requested file is resumed. same goes to pre-retr event.
Quote:
Originally Posted by Yil
Let me know if you think that would dramatically change the number of times the script would be called in your implementations and if that would be desirable.
|
in my case the whole point is that contents of virtual directory is about never the same, it is changed constantly so caching isn't helping me at all. so it seems like a waste to enable caching (=> memory consuming) functions for directory that doesn't require it.
Quote:
Originally Posted by Yil
I also liked the ":" link prefix idea I mentioned before.
|
it seems like a nice idea. but to me actually NOT adding ":" should return usual name, and adding it return a symlink
p.s. also check the situation when a declared virtual directory path already exist and it is a non-empty mountpoint. ioftpd crashes while only warning should have been issued.