[Mingw-msys] POSIX names for drive letters

Schwarz, Konrad konrad.schwarz@siemens.com
Tue Aug 29 09:23:00 GMT 2006


> -----Original Message-----
> From: mingw-msys-bounces@lists.sourceforge.net 
> [mailto:mingw-msys-bounces@lists.sourceforge.net] On Behalf 
> Of mwoehlke

> > The proposed mapping for directory `C:\' is `//./C$/' (or perhaps 
> > `//./C/').

> So... why exactly do you need this? The only thing I might 
> actually support here (keeping in mind Eric's comments and 
> CGF's clear agreement with them) would be treating '//./' as 
> a special case of '//127.0.0.1/', at which point '//./C$/' is 
> the UNC mapping of the default 'C$' share on the local 
> machine. But I still fail to see why that is useful.

My program constructs file names.  Specificially, for code generation,
it outputs `# include' statements, which reference pre-installed header
files.  To maximize the portability of the code, I would like to use
relative paths wherever possible, so that the generated code can more
easily be moved to a different location, assuming that the referenced
files are moved too.  A related and perhaps more pertinent example is to
be able to compile the generated code on a second computer that shares a
network drive with the original computer and/or under a different
operating system, such as Win32.

For that, I need to know when it is possible to construct a relative
path, which is when the two files are on the same drive.  As a matter of
fact, for Cygwin and for Interix, `/cygdrive/D/dir1/../../C/dir2/file'
and `/dev/fs/D/dir1/../../C/dir2/file' works, but it does not work for
MinGW: `/d/dir1/../../c/dir2/file' fails.  For the cross-generation
example, it is debatable if `/cygdrive/D/../C' is helpful since it
imposes strong constraints on the name of the drive mount point on the
remote machine and fails for Win32.

Thus my suggestion of using a name prefixed with two slashes to indicate
a path that does not fully comply with the ordinary name-resolution
rules, as sanctioned by POSIX.  The code that does the file name
normalization can remain largely platform independent and refer to files
outside of the current file system hierarchy by extra linguistic means
such as `# include <>' and `-I' flags.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/



More information about the Cygwin mailing list