Reports wrong URI for "No such file or directory".

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue for you. Can you try with the latest Ubuntu release? Thanks in advance.

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!

Sorry, I missed the query.

Yes, this is still reproducible in 0.12~pre2.dfsg0-1ubuntu1 (Jaunty). Didn't check -1ubuntu2 (Karmic), but reproducing it is trivial. Simply providing an html file with "frame" elements pointing at non-existent files should produce the problem.

FWIW, the problematic files were fetched via the command: "wget -rl1 -HkE www.fdoxnews.com". If wget version 1.12 is used (not yet available in Ubuntu repositories), the resulting www.fdoxnews.com/index.html file will _not_ contain the invalid question-mark shown below (as I've fixed that bug), so you'd need to replace the %3Fs with ?s by hand (or, yeah, just change them some other way so they don't point to valid files).

To be abundantly clear: the problem is just that elinks names the wrong file as "Not a file or directory".

wget version 1.11.4-2ubuntu2
elinks version 0.12~pre5-1ubuntu2

Using Karmic, wget to download www.fdoxnews.com and elinks to open the fdoxnews.com/index.html file shows no problems at all. I can only assume that this is fixed in Karmic. Marked Fix Released.

Teej, could you please verify that the fdoxnews.com/index.html contained links to non-existent files (or malformed links)? ...or just replace the frame links with ones to obviously invalid files? ...if the html file shows "no problems at all", then it doesn't sound to me like you're reproducing it properly (there _should_ be an error: the error should be different).

As far as I can see there are no incorrect links. I tested every single one on the main page of the wget download of www.fdoxnews.com and every link on that main page resolved correctly to the appropriate file://..... link. If I have missed something let me know, I will restest it :)

Teej, I'm afraid you're missing the point: until you ensure that the links _are_ incorrect (and they must be file:// links), then you're not testing it. Please break the links, and check the error message. If it says the origin page is missing, rather than the frame-sourced pages, then it's still broken.

Sorry micah, I've never used elinks, and it seems I'm the only triager here, but I will notify the team and see if they have any experience with this. It may help to provide full step by step instructions to reproduce this, but hopefully as I've been next to no help, someone should be able to work on this for you. Thank you and good luck :)

micah, please describe a little better what you're trying to say. what's "break the links"? can you provide such a set of html files?

I decided to investigate this one since I'm a console-junkie and use elinks a good bit.

I was able to reproduce this by doing the following:

1) Downloaded the fdoxnews.com site with the following command: wget -rl1 -HkE www.fdoxnews.com
2) Pointed elinks at it. Page displays correctly.
3) Edited the index.html to change the %3F entities with regular ?s.
4) Pointed elinks at it. Elinks complains as follows:
Unable to retrieve file:///home/steve/testing/www.fdoxnews.com/index.html:
No such file or directory

This is definitely a misleading error. Note that I am using elinks 0.12~pre5-1ubuntu2 on Karmic.

Thanks, all.

Dimitrios, Teej, I had thought that Steve's steps were the ones I'd outlined; but I guess I was a bit too convoluted in my explanation. Thanks for your patience.

I'm surprised that wget is doing the right thing with respect to "?" versus "%3F"; I guess I must have fixed it earlier than I had thought (or else Debian imported the change from the mainline branch).

This bug has been forwarded to Debian, so is being marked Triaged. Any further discussion/progress on this bug should be put to the Debian bug tracker. Thank you again for reporting this to us.