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

Bug #122499 reported by Micah Cowan on 2007-06-27
Affects Status Importance Assigned to Milestone
elinks (Debian)
elinks (Ubuntu)

Bug Description

Binary package hint: elinks

In a file, obtained via wget (along with the relevant frame target file), there is:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
        <META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<FRAMESET rows="100%,*" border=0 frameborder=0 framespacing=0>
        <FRAME name=top
        src="../" noresize>

The actual file in ../ contains the question-mark, literally as you see it. (Since the --convert-links option was specified to wget, it was wget's responsibility to encode the question mark in the frame src attribute; as the current maintainer of GNU wget, I've made a note of this problem.)

The file whose contents are given above resides in /tmp/ When elinks is invoked on that file, it of course can't find the frame target (since it is looking for index.mas, and not index.mas?epl=0044.... However, instead of reporting that it can't find that file, it instead gives:

Unable to retrieve file file:///tmp/

No such file or directory.

This is misleading, as in fact it finds that file just fine; just not the embedded frame target. This is confirmed via strace.

I will attach the strace output, which should be sufficient data to confirm this bug.

Micah Cowan (micahcowan) wrote :

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.

Changed in elinks (Ubuntu):
status: New → Incomplete
Chuck Short (zulcss) wrote :

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!

Changed in elinks (Ubuntu):
status: Incomplete → Invalid
Micah Cowan (micahcowan) wrote :

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". If wget version 1.12 is used (not yet available in Ubuntu repositories), the resulting 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).

Changed in elinks (Ubuntu):
status: Invalid → New
Micah Cowan (micahcowan) wrote :

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 and elinks to open the file shows no problems at all. I can only assume that this is fixed in Karmic. Marked Fix Released.

Changed in elinks (Ubuntu):
status: New → Fix Released
Micah Cowan (micahcowan) wrote :

Teej, could you please verify that the 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).

Changed in elinks (Ubuntu):
status: Fix Released → New

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 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 :)

Micah Cowan (micahcowan) wrote :

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 :)

Dimitrios Symeonidis (azimout) wrote :

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?

Changed in elinks (Ubuntu):
status: New → Incomplete
Steve McGrath (smcgrath23) wrote :

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 site with the following command: wget -rl1 -HkE
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/
No such file or directory

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

Changed in elinks (Ubuntu):
status: Incomplete → Confirmed
Changed in elinks (Ubuntu):
importance: Undecided → Low
Micah Cowan (micahcowan) wrote :

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.

Changed in elinks (Ubuntu):
status: Confirmed → Triaged
Changed in elinks (Debian):
status: Unknown → New
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.