Browsers Resolving Symbolic Link (e.g. Windows Shortcuts)

[Five By Five]

Does anyone know if Firefox (or IE?) running in a Microsoft Windows
environment requesting a resource via LINK element will be given by the OS
the file if it is referenced through a symbolic link?

For example,

The HTML document has the following element:

<link href="style/std.css" type="text/css">

The HTML document is located physically in the absolute path
'D:\Programming\My Interactive Pages\' using standard conventions of the
Windows operating environment.

That path also contains a subdirectory (subfolder) 'style' in the same
directory, and the subdirectory 'style' contains the file 'std.css' which
is a Windows shortcut file. The shortcut points to 'C:\style\std.css'.

Naturally, if the 'std.css' were a real CSS file, the HTML document is
correctly styled.

But when 'std.css' is made a shortcut file type, the browser apparently
reads the contents of the shortcut file, which are not CSS and therefore
not understood, and default styling is used to render the markup.

I am not sure what happens for browsers operating in Unix-type
environments, but does anyone know how to make the Windows system provide
the contents of the file-pointed-to-by-the-shortcut (symbolic link) rather
than the shortcut (symbolic link) itself?

 

[William Gill]

Does anyone know if Firefox (or IE?) running in a Microsoft Windows
environment requesting a resource via LINK element will be given by the OS
the file if it is referenced through a symbolic link?

For example,

The HTML document has the following element:

<link href="style/std.css" type="text/css">

The HTML document is located physically in the absolute path
'D:\Programming\My Interactive Pages\' using standard conventions of the
Windows operating environment.

That path also contains a subdirectory (subfolder) 'style' in the same
directory, and the subdirectory 'style' contains the file 'std.css' which
is a Windows shortcut file. The shortcut points to 'C:\style\std.css'.

Not sure this is the appropriate place to ask your question, but maybe
if we can help clear up a couple of your misconceptions it will either
clear up your problem or redirect you in a more appropriate direction.

First off what you are asking about is a file system issue, not HTML or
CSS. The only connection to HTML or CSS is via the http server (a
program running on a particular OS and file system), the program that
interprets a request from your browser and "serves" a resource
(document, etc.). So what ever the server decides to "serve" will be
dictated by either the file system's interpretation, or server options.
In either case the request can be translated from what was asked for,
to what is actually delivered ("if they ask for this, give them that").
For example your question asked this group a question. You could (and
like should have) received a 303 status ("the resource you request is
located elsewhere"), but I have chosen to "translate" your request, and
provide (what I hope is) some helpful resource.

Secondly a windows "shortcut" is not a symbolic link. A shortcut is more
like a HTML "bookmark", it is a reminder placed in a convenient place
reminding you where to find what you want, or reminding you what to ask
for. When your browser requests a resource (a shortcut file), the HTTP
server dutifully serves that resource, it doesn't try to read and
understand that resource and translate your request for you. A symbolic
link on the other hand provides an "alias" name for the file in the file
system.

 

[Adrienne Boswell]

Does anyone know if Firefox (or IE?) running in a Microsoft Windows
environment requesting a resource via LINK element will be given by
the OS the file if it is referenced through a symbolic link?

For example,

The HTML document has the following element:

<link href="style/std.css" type="text/css">

The HTML document is located physically in the absolute path
'D:\Programming\My Interactive Pages\' using standard conventions of
the Windows operating environment.

That path also contains a subdirectory (subfolder) 'style' in the same
directory, and the subdirectory 'style' contains the file 'std.css'
which is a Windows shortcut file. The shortcut points to
'C:\style\std.css'.

Naturally, if the 'std.css' were a real CSS file, the HTML document is
correctly styled.

But when 'std.css' is made a shortcut file type, the browser
apparently reads the contents of the shortcut file, which are not CSS
and therefore not understood, and default styling is used to render
the markup.

I am not sure what happens for browsers operating in Unix-type
environments, but does anyone know how to make the Windows system
provide the contents of the file-pointed-to-by-the-shortcut (symbolic
link) rather than the shortcut (symbolic link) itself?

Browsers don't know anything about shortcuts. They read a file, and if
they are able to parse it, they do so, nothing more, nothing less.

 

[Five By Five]

Browsers don't know anything about shortcuts. They read a file, and if
they are able to parse it, they do so, nothing more, nothing less.

I agree. My question is why the operating environment/system does not
deliver to the browser application what it is seeking, or if it can be
made to do so. I figure I would ask here because this would be an answer
that HTML document writers might have experience with. Perhaps it's
better to put this to a group familiar with the Windows operating
environment.

 

[Five By Five]

Not sure this is the appropriate place to ask your question, but maybe
if we can help clear up a couple of your misconceptions it will either
clear up your problem or redirect you in a more appropriate direction.

First off what you are asking about is a file system issue, not HTML
or CSS.

I agree that this is specific to the response or activities of an
operating system or environment. I put the question here though because
HTML document preparers put the document on a computer system and they
must specify a reference to the resource(s) they use in the rendering of
the document. Many of those who prepare and place HTML documents use some
rather common or widespread operating environments, such as Windows or
Unix, They would probably read this newsgroup and have the experience of
the unique or idiosyncratic features such as a "href" or "src" attribute
to an element retrieving a resource INDIRECTLY, namely through a system
feature such as a symbolic link/shortcut to the resource.

The only connection to HTML or CSS is via the http server (a
program running on a particular OS and file system), the program that
interprets a request from your browser and "serves" a resource
(document, etc.). So what ever the server decides to "serve" will be
dictated by either the file system's interpretation, or server
options.
In either case the request can be translated from what was asked
for,
to what is actually delivered ("if they ask for this, give them
that").
For example your question asked this group a question. You could
(and
like should have) received a 303 status ("the resource you request is
located elsewhere"), but I have chosen to "translate" your request,
and provide (what I hope is) some helpful resource.

Yes, it is true that the client making the request via the 'href' or
'src' to the server would have no idea the mechanism of how the resource
is retrieved. I am wondering specifically about how the server finds the
resource (if the request is made with the http protocol).

My development activities are not requesting the HTML document or its
dependence on resources through the 'http' protocol, if this is of any
consequence. I am actually reading the document into the browser through
the local filesystem (one browser refers to it as the 'file' protocol,
while another just presents the document as the absolute path describing
the local filesystem.

Secondly a windows "shortcut" is not a symbolic link. A shortcut is
more like a HTML "bookmark", it is a reminder placed in a convenient
place reminding you where to find what you want, or reminding you what
to ask for. When your browser requests a resource (a shortcut file),
the HTTP server dutifully serves that resource, it doesn't try to read
and understand that resource and translate your request for you. A
symbolic link on the other hand provides an "alias" name for the file
in the file system.

The shortcut in Windows actually appears to act exactly like the symbolic
link in a Unix file system. If you attempt to "open" the Windows shortcut
or the Unix symbolic link that refers to the resource in the file system,
the system operations of opening act on the resource itself rather than on
the object/resource whose role it is to act as a pointer or reference to
the resource (i.e., link/shortcut).

While a server (process) to a client requesting resources for an HTML
document might not be expected itself to understand the nature of the
resource found through a URL, the operating system (kernel) upon which it
caries out its tasks would be expected to understand and resolve this.

But perhaps you are right, and there is a better forum for this question.

 

[William Gill]

I agree. My question is why the operating environment/system does not
deliver to the browser application what it is seeking, or if it can be
made to do so. I figure I would ask here because this would be an answer
that HTML document writers might have experience with. Perhaps it's
better to put this to a group familiar with the Windows operating
environment.

As stated before, a Windows "shortcut" is not a symbolic link. There is
a mechanism for creating "junction points" (similar to symbolic links,
but limited to in NTFS, but based on what appears to be your familiarity
with Windows, I would advise exercising the utmost caution. It is easy
to delete a target directory when you intended to delete the junction point.

 

[Five By Five]

As stated before, a Windows "shortcut" is not a symbolic link. There
is a mechanism for creating "junction points" (similar to symbolic
links, but limited to in NTFS, but based on what appears to be your
familiarity with Windows, I would advise exercising the utmost
caution. It is easy to delete a target directory when you intended to
delete the junction point.

The information on directory junctions was sufficient to point to
information that reports that the Windows Vista system---what I am
using---actually now incorporates Unix-like symbolic links, whereas
earlier systems (XP, for example) required the use of the directory
junction feature you describe. The information I found is here:

http://en.wikipedia.org/wiki/NTFS_symbolic_link

In addition, junction points are different in Windows Vista compared to
earlier systems. For instance, the following applies when manipulating
junction points in the Windows Explorer application under Vista:

<quote>
* Junction points are indicated with an arrow icon overlay.
* Deleting a junction point using explorer is now safe.
* A junction point can be restored from the recycle bin
</quote>

http://en.wikipedia.org/wiki/NTFS_junction_point

 

[William Gill]

The information on directory junctions was sufficient to point to
information that reports that the Windows Vista system---what I am
using---actually now incorporates Unix-like symbolic links, whereas
earlier systems (XP, for example) required the use of the directory
junction feature you describe. The information I found is here:

I am glad that helped. The point is "shortcuts" are not symbolic links.

As for use of the FILE: protocol (as you mention elsewhere), it might be
worth the effort to install a true HTTP server (i.e. Apache) in your
development environment. There are a lot of shortfalls in file protocol.

 

[Raymond Schmit]

I agree. My question is why the operating environment/system does not
deliver to the browser application what it is seeking, or if it can be
made to do so. I figure I would ask here because this would be an answer
that HTML document writers might have experience with. Perhaps it's
better to put this to a group familiar with the Windows operating
environment.

HTML and webservers works on files located on virtual directories or
urls, not on C:\blabla... nor on D:\blabla....

 

[William Gill]

HTML and webservers works on files located on virtual directories or
urls, not on C:\blabla... nor on D:\blabla....

Try replacing "http://" with "file:// plus the path to any html file
on your computer. No server other than the browser and the file system
are required. The OP's problem was with confusing a windows shortcut
with a (unix) symbolic link.

 

[Raymond Schmit]

Try replacing "http://" with "file:// plus the path to any html file
on your computer. No server other than the browser and the file system
are required. The OP's problem was with confusing a windows shortcut
with a (unix) symbolic link.

The use of a browser is 99%( or more) for accessing "http://" and not
for accessing "file://

 

[rf]

The use of a browser is 99%( or more) for accessing "http://" and not
for accessing "file://

Except for when one is testing pages on the local file system, before
uploading to a server somewhere.

 

[Chris F.A. Johnson]

Except for when one is testing pages on the local file system, before
uploading to a server somewhere.

Or when the browser is also the file manager.

I often use file:// for checking local files, but I don't use it
to check web pages. I use http:// and a local server. Much of the
time file:// wouldn't work for that as I use a lot of server-side
includes.

 

[William Gill]

The use of a browser is 99%( or more) for accessing "http://" and not
for accessing "file://

Even if your numbers were somehow supportable, the OP states he is in
the 1%. The percentage of users using file:// vs using http:// (vs
ftp://, or https://) has no bearing on his problem;

"Ninety percent of this game is mental, and the other half is physical."
(Yogi Berra) That still doesn't have anything to do with the stated
problem.

 

[Raymond Schmit]

Except for when one is testing pages on the local file system, before
uploading to a server somewhere.

I prefer using a local webserver, because testing on local file system
did not always show what will be when uploaded.... and also because
some of my pages contains php parts.

 

[William Gill]

Huh? I use a local server to write and test pages all of which are PHP.
What's the problem?

Ed, I think you are misreading Raymond. I believe he is saying that
that (server scripted pages) is why he uses a local server instead of
the file:// protocol.