Re: Patch for remote files in dnd.el

["Stuart D. Herring" <herring@lanl.gov>]

> I'm not sure if file:////REMOTEHOST/DIRECTORY/NAME or
> file://localhost//REMOTEHOST/DIRECTORY/NAME is invalid or not.  But
> even the current code uses invalid file:/DIRECTORY/FILE. :-)

See RFC 3986, section 3.2.2.  file:/dir/file is equivalent to
file:///dir/file and to file://localhost/dir/file.  In the first two cases
you mention, the "path" component of the URI is
"//REMOTEHOST/DIRECTORY/NAME", and it is up to the authority (in this
case, the system file name interpreter and file system) to determine its
meaning; presumably Windows interprets "//R/D/N" as being a UNC path.

The trick is in section 3.3: URIs without authority components (like
"file:/DIRECTORY/FILE") can't have paths that begin with two slashes,
since two slashes begin the authority.  So
"file://REMOTEHOST/DIRECTORY/NAME" is a file on a machine whose FQDN is
REMOTEHOST (according to RFC 1738), although I imagine that most systems
would simply attempt to resolve REMOTEHOST as a hostname (thus succeeding
with local names and local DNS systems) or, perhaps, would use some sort
of file-sharing protocol (like SMB) and interpret REMOTEHOST as an
identifier for use with it.

In short, "file:/dir/file" is valid, but perhaps only one of
"file://host/dir/file" and "file:////host/dir/file" will work (with any
given file-sharing arrangement).  Whichever mode seems to work with
existing arrangements should be used (even for local files, for
consistency).  Are there even any schemes in common use other than UNC? 
NFS in typical use doesn't involve URIs, and even in "public handle" use
involves nfs: URIs, not file:.

URIs are confusing business!  Hope this helps.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.