Won't resolve symlinks with ".[pP][sS]" in the dirname.

Zio · 09-26-2002, 05:12 AM

It seems FlashFXP have a problem to resolve symlinks that contains the part ".[pP][sS]".

To explain this further I will use an example.
A symlink called "A.BC.D-Zio" pointing to "Zios_dir" works just fine.
A symlink called "A.PS.D-Zio" pointing to "Zios_dir" doesn't.
The problem is not case sensitive, i.e. A.ps.D-Zio gives the same error.

What should also be mentioned is that it doesn't matter what the dirname is called which the symlink is poiting to. It can be a dir called "A" or "ABCD-Zio" or whatever.
FlashFXP also have no problem in resolving an actual dir with the mentioned part in it.
The problem has been in FlashFXP as long as I can remember, and is still in 2.0x.

I can't find any setting that should/could affect this.
The symlinks work with regular ftp (*nix/Windows), NFTP, ... .

I also have a question regarding symlinks that I can't find answered in docs or settings.
Let's say you have a dir with two symlinks, A and B.
A points to ../subdir1/Dir_A and B points to ../../maindir3/subdir2/Dir_B.
When following the symlink FlashFXP resolves the link and CWDs to the actual path. That means that when issuing "cd .." to jump back a step you won't end up in the dir you came from, but instead you will end up in ../subdir1 or ../../maindir3/subdir2.
Is there no way to cloak this? Several other FTP clients have this feature/option.

/Zio

bigstar · 09-26-2002, 11:28 AM

FlashFXP doesn't validate links, it has a pre-defined list of known file extensions/names. If the file name matches then it's treated as a file. In future versions we plan on adding an option to automatically validate links to determine if they're in fact a file/folder, though validation can be quite slow depending on the number of links.

I don't have access to the FlashFXP source code right now, but I suspect there might be a problem with the pattern matching causing that mask to be treated as a file. As soon as my main pc is back up and running i'll look into it.

bigstar · 09-29-2002, 08:27 PM

It appears my pattern matching was doing a wild card *.ps* match rarther than comparing the extension. I have made changes to the code so that only a *.ps match is possible.

Zio · 09-30-2002, 02:41 AM

Won't that just result in a symlink with a dirname ending in .ps not to be resolved?
I don't know why you use pattern matching, but I'm sure there must be some easier way to decide if it's a link or not.
In *nix it is an attribute in the file access permission.
A filename has -xxxxxxxxx, a dirname has dxxxxxxxxx and a link has lxxxxxxxxx. I don't know how it is handled on Windows systems though.

/Zio

bigstar · 09-30-2002, 03:02 AM

yes it would.. the only 100% solution is to validate each and every link to determine if it's a folder/file. this is done by attempting to change into the link. If it's a file it would fail. We plan to add this feature in future versions of FlashFXP.

A link doesn't tell you if it's a file or a folder, the client must determine the type on it's own.

Zio · 09-30-2002, 03:24 AM

I do understand that a link doesn't tell if it's to a file or folder.
But wouldn't the smartest thing be to just display the link properly without caring if it's to a file or folder.
The check for the link beeing to a file or folder can be done when the user requests to follow the link.
I believe that's how it's done on a system.
I'm no expert in the area though.

/Zio

bigstar · 09-30-2002, 01:14 PM

That could be done, we'll consider that in future versions. Although when it comes to automation a prompt isn't the best solution if no one is around to making a choice.