Re: Added some interesting functionality to my cygwin sandbox

[Elfyn McBratney <elfyn at cygwin dot com>]

On Wed, 2 Jul 2003, Igor Pechtchanski wrote:

> On Wed, 2 Jul 2003, Elfyn McBratney wrote:
>
> > On Wed, 2 Jul 2003, Igor Pechtchanski wrote:
> >
> > > On Wed, 2 Jul 2003, Christopher Faylor wrote:
> > >
> > > > On Wed, Jul 02, 2003 at 08:33:41AM +0200, Corinna Vinschen wrote:
> > > > >On Tue, Jul 01, 2003 at 10:45:04PM -0400, Christopher Faylor wrote:
> > > > >> We could use nul bytes for this, I suppose.  No one has to read the file.
> > > > >
> > > > >Isn't the new way of coding special characters also a way to represent
> > > > >a cygdrive by using an otherwise non-existing %xx expression?  E.g. using
> > > > >just one character after the percent like
> > > > >
> > > > >    %c/c/foo
> > > > >
> > > > >or otherwise not used characters like uppercase
> > > > >
> > > > >    %CD/d/bar
> > > > >
> > > > >for instance?
> > > >
> > > > That's an interesting idea.  It would only work on "posix" mounted
> > > > directories, though.
> > > >
> > > > cgf
> > >
> > > Here's another idea: the shortcuts already contain the Win32 path to the
> > > file.  Instead of redundantly repeating that path in the comment field of
> > > the shortcut in place of the POSIX path, we could use an empty comment
> > > field to indicate that the Win32 path should be used (does anyone know if
> > > it's legal to create a symlink to an empty path on Unix?).
> >
> > I don't think so. That'd just be a dead symlink.
>
> Why?  I just tried it on Linux, and could not create a symlink to an empty
> path.  If we added some logic to link processing code in Cygwin to revert
> to the Win32 path if the POSIX path is empty, I don't see any reason why
> this woulnd't work...  It won't even be a slowdown for normal symlinks,
> since we'd only do this bit of logic if we failed to open the POSIX path.
>
> > But as we're trying to get around a problem with cymlink destinations
> > how about having an internal name like the cygdrive prefix? That way we
> > could guarentee that it would point to the correct location.
> >
> > Elfyn
>
> Yeah, that's the previously suggested alternative.  However, I'm wary of
> any hard-coded valid paths...  Corinna's idea is basically that, but with
> the path that's normally invalid.

I like the idea. Personally I'd like to see something like /dev/filesystem (the
name doesn't matter) like DJGPP uses. Or, even better IMO, /dev/hda[123456...]
which links to the appropriate device (\Device\HardDisk0\Partition..). Perhaps
that's straying from the point.

Elfyn
--