> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] 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/
