FlashFXP Forums - View Single Post

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.

10-11-2009, 07:56 PM
Yil Too much time... Join Date: May 2005 Posts: 1,194	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.