FlashFXP Forums - View Single Post

Yil · 05-27-2010, 01:12 AM

It appears that dealing with NTFS junctions on a remote filesystem is hard... I can now detect when the directory is non-local but when I run into the junction I don't really have any way to determine the actual target since it's a remote path and that means nothing from looking at the directory mount point on the local machine since I don't know the base path for it. It's easy enough to just ignore the link similar to how IGNORE treats local junctions and that's what I'm probably going to do, but in that case you loose the nice features of SYMLINK mode...

I think I can add a requirement that the directory mounted in the .vfs file contain a special marker (chattr, or a file like .ioFTPD.base or something) that contains the base path on the server which I load in when loading new .vfs files.

However, there are 2 other options that I think work with network shares. I can teach ioFTPD how to parse .lnk files which is something I looked into when I did the NTFS junction stuff for v7 but didn't think worth doing, or on Vista+ the server could use symlinks which can refer to mountpoints and should function just like junctions... ioFTPD handles symlinks just like it does junctions so it's already supported, but the server just doesn't create them since you need to give the user account the ability to do so and I figured why bother when junctions work fine, but I obviously didn't count on network shares...

I've learned a lot though. I can detect remote NTFS junctions, and then figure out if the target path is on the same physical volume as the link which is useful. Now I just need to figure out how to put it all together.

I'm thinking I might need a new TCL function to make things easier for scripters though. Something along the lines of a create symlink function that would create a local NTFS junction if possible, else a symlink if supported, or maybe the .lnk style link, else a ioFTPD symlink. The trick is no matter which gets created it must be reverse resolvable to a VFS path for SYMLINK mode if that would have been possible locally. It turns out that might not be so hard for links TO network shares, but it's actually trickier for links on the network share that point BACK to local drives... Like suppose someone wanted to put the /Requests or /Incomplete dir on a remote filesystem. That wouldn't work if it tried to use junctions for everything.

It really is nice to see the links in explorer and be able to click on a dir and actually have it take you to the right place instead of having to do it in the FTP all the time, so I've got some incentive to get a workaround using filesystem links instead of ioFTPD symlinks.

Going to give it a day or two and see what ideas come to mind, but if someone has any ideas feel free to chime in.

05-27-2010, 01:12 AM
Yil Too much time... Join Date: May 2005 Posts: 1,194	It appears that dealing with NTFS junctions on a remote filesystem is hard... I can now detect when the directory is non-local but when I run into the junction I don't really have any way to determine the actual target since it's a remote path and that means nothing from looking at the directory mount point on the local machine since I don't know the base path for it. It's easy enough to just ignore the link similar to how IGNORE treats local junctions and that's what I'm probably going to do, but in that case you loose the nice features of SYMLINK mode... I think I can add a requirement that the directory mounted in the .vfs file contain a special marker (chattr, or a file like .ioFTPD.base or something) that contains the base path on the server which I load in when loading new .vfs files. However, there are 2 other options that I think work with network shares. I can teach ioFTPD how to parse .lnk files which is something I looked into when I did the NTFS junction stuff for v7 but didn't think worth doing, or on Vista+ the server could use symlinks which can refer to mountpoints and should function just like junctions... ioFTPD handles symlinks just like it does junctions so it's already supported, but the server just doesn't create them since you need to give the user account the ability to do so and I figured why bother when junctions work fine, but I obviously didn't count on network shares... I've learned a lot though. I can detect remote NTFS junctions, and then figure out if the target path is on the same physical volume as the link which is useful. Now I just need to figure out how to put it all together. I'm thinking I might need a new TCL function to make things easier for scripters though. Something along the lines of a create symlink function that would create a local NTFS junction if possible, else a symlink if supported, or maybe the .lnk style link, else a ioFTPD symlink. The trick is no matter which gets created it must be reverse resolvable to a VFS path for SYMLINK mode if that would have been possible locally. It turns out that might not be so hard for links TO network shares, but it's actually trickier for links on the network share that point BACK to local drives... Like suppose someone wanted to put the /Requests or /Incomplete dir on a remote filesystem. That wouldn't work if it tried to use junctions for everything. It really is nice to see the links in explorer and be able to click on a dir and actually have it take you to the right place instead of having to do it in the FTP all the time, so I've got some incentive to get a workaround using filesystem links instead of ioFTPD symlinks. Going to give it a day or two and see what ideas come to mind, but if someone has any ideas feel free to chime in.