However, after providing the destination the log entry says:
550 pub/ibmpc/dos/apps/pmail/pmail-addons.txt: No such file or directory
At this point you are looking at the directory in question, and clearly seeing the file as present.
A doubleclick on it would quite often result in the same errormessage.
I use DO as the default ftp client, and this issue can also be reproduced via the run dialog by entering the same url.
The result of this is "An error occured while copying 'pmail-addons.txt': The system cannot find the file specified. (2)", essensially the same as above.
Can you guys reproduce it?
Is this a bug, or is it intentional for some reason?
This is funny behavior. On my computer (XP SP2), here is what happens:
A destination dialog prompt is displayed, and once I select a destination folder, the file in question is copied there w/o any problem.
Meanwhile, the FTP site is shown in the current lister. However, if I manually select the file in this lister (after the successful copy job in step 1), then try to open it, I get the same error message.
Once I hit Refresh on the FTP site lister's toolbar, everything works fine from that point on.
So this looks like an intermittent issue, at least on my computer.
to make it work flawlessly (note the extra slash before 'pub').
AFAIR there has been at least one thread about the FTP address syntax in Opus, with people debating whether the strictly standard syntax (using the extra slash) is an advantage or an annoyance.
This is one of the strange quirks of DO compared to others..
To be honest, DO is the first and only program I've seen using that notation, and not the normal one.
However, apparently both are valid according to the rfc's, DO just has less support for the normal one in some cases.
I have no problem with DO using // syntax, as long as it supports the "normal" syntax too.
As I understand things (which may be wrong), it seems incorrect that those two URLs have different results.
Anonymous logins to ftp://ftp.demon.co.uk put you into the root dir '/' by default, so a path relative to the default dir should be the same as an absolute path relative to the root.
Perhaps there is a good reason for it. Either way, I've reported it to GPSoftware for their consideration.
Btw, strangely enough DO still present the exact same directory in both cases (when using GO).
However, it still can't find the files in the directory when using Open or Download in some cases/quite often.
when you tried it, did you use single slash notation?
It seems a bit strange that you managed to do this without a hitch.
Apparently I can do it too on occation, but not on first attempt.
I'm not sure what the prerequisites are yet.
The reason for this is that DO can (and I guess it is the default when you install) be used as the default handler for the ftp protocol, and because of this it really should be prepared for urls using ftp:// and "normal" notation (in addition to the // notation).
I have no trailing space when I'm doing the tests.
I tried doing it your way this time, by pasting it into Quick connect's ftp host field.
The result wasn't any different (it noted that pub/ibmpc/dos/apps/pmail/pmail-addons.txt wasn't a directory in the log).
It changed to the correct path, asked for a destination, then displayed file not found regarding pmail-addons.txt (see log).
Using a straight copy worked perfectly with the exact same url in a repeatable manner:
COPY ftp://ftp.demon.co.uk/pub/ibmpc/dos/apps/pmail/pmail-addons.txt TO D:\TMP\
Using GO doesn't work (error file not found):
GO ftp://ftp.demon.co.uk/pub/ibmpc/dos/apps/pmail/pmail-addons.txt
Calling DO the same way DO's FTP handler doesn't work either. (error file not found):
Are you running some sort of transparent proxy (like AntiVirus with TCP/IP monitoring for example) that might be getting in the way and causing this problem? I don't doubt you're seeing it but it's odd that the same URL is working fine for others.
If you didn't already it's worth checking the FTP log (Tools -> Output Window) for all the different attempts. If you're trying one method straight after the other and didn't close the original window and let Opus finish disconnecting then the failure could be because the site doesn't let you have an additional login at that time.
There's definitely something up though as I can confirm that I see something slightly different happen depending on which URL I use, but it never fails to show the folder or anything like that.
I've tried iterating through all possible methods I know of with restarting DO between each (making sure to exit the previous one on one of the local drives, ftp cache off).
It never fails showing the directory, but what it does after is the big question.
Sometimes it seems to forget or skip issuing the last command (to retrieve the file), because nothing shows in the log after retrieving the filelist.
If the reason for this is that DO couldn't find the file in the list so it just ignored it, then it must do something wrong somewhere as everyone can see the file in question are present at that location.
