Closed Bug 17964 Opened 25 years ago Closed 25 years ago

File/directory names with '#' on local fs broken.


(Core :: Layout, defect, P3)






(Reporter: ramune, Assigned: jud)


(Whiteboard: [PDT+] [02/11/00])

When browsing the local filesystem via: file://localhost/path/to/place, trying
to open a directory or a file with a '#' in its name will simply list the
entries in the same directory as that. i.e.: if a/ contains b/, c/, and #/,
a/# will list: b/, c/, and #/.  If a file with a '#' in it is accessed, the
contents of that directory will simply be shown again.
CVS checkout on Wed Nov 3 21:42:45 - 22:03:53 PST 1999
Linux 2.3.25, glibc-2.1.2, gcc-2.95.1
Assignee: troy → valeski
Doesn't sound like layout.
Blocks: 18471
This is a funny urlparsing case. # is a special character in an normal url. It
separates the reference part from the filename.

You can see this funny behaviour when creating a directory

xx with file zzz in it

and a directory

xx#yy with a file yyy in it.

When clicking on xx#yy you get zzz as file, because you are really in directory

This is ugly but there is little hope here because I can think of some cases
where file-URLs could have a ref-part. So we can't dismiss this and treat # as a
normal char.
perhaps encoding the url first would help?
This might be an option if the click on the path would deliver the encoded path
back. However, what happens if the filepath is typed into the urlbar? # is a
character that should be encoded if it is not the ref-character.

If we could savely assume that there would be no / after a # in an URL or at
least in a file-URL, we could ignore the # in the path and get it right. I
currently don't kwow how this will do with # in a filename but it may be a
Target Milestone: M13
I have now again something working in URLparsing that does ESCAPING/UNESCAPING.
Where can I find that stuff that does the directory tree in the layout when
viewing file://... ? Want to try something ...
xpfe/components/directory/nsDirectoryViewer.cpp does the http index parsing. Is
this what you're after andreas?
Depends on: 13449
Target Milestone: M13 → M14
making this bug dependent on the url parsing meta bug.
No longer depends on: 13449
partial fix for this in ANDREAS_URL_BRANCH
Keywords: beta1
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]
andreas, is this sucker gone?
This is only partially fixed, because only nsDirectoryViewer is now able to do
this kind of stuff for you. It is still possible to put a # in the urlbar as
part of a filename and get this mistaken as a REF.

Maybe we need a very smart part of webshell which can detect that this # is
infact part of a filename and has to be escaped before given to nsStdURL.
Whiteboard: [PDT+] → [PDT+] [02/11/00]
I'm able to view dirs with '#' in them, and load files with '#' in the filename. 
Marking fixed.
Closed: 25 years ago
Resolution: --- → FIXED
With the Feb 09 build, this problem appears to be fixed. Tested under Linux Red 
Hat 6.0
No longer blocks: 18471
You need to log in before you can comment on or make changes to this bug.