Mail Archives: cygwin/2006/08/07/17:15:12
> Is there some reason why you aren't just using cygwin's symlink()
> function? Reverse engineering and mimicking cygwin's symlinks seems to
> be a pretty fragile way of writing an application which will play nicely
> with cygwin. What if we change the way symlinks are written at some
> point?
Yeah, I agree we are taking this risk. We have a client process running
on cygwin, but Coda's interaction with the Windows NT kernel sort of
sits below cygwin, through the use of a kernel module also loaded as an
NT service (we simply write to and read data from the device /dev/cfs,
and cygwin is none the wiser). Thus the kernel module doesn't create
files using cygwin's file system interface, it only provides another
file system within its namespace.
We theoretically could use symlink() in the userspace client, but we'd
have to introduce a lot of cased #ifdef _CYGWIN32_ code to create the
file and change the kernel/userspace interface to handle the
cygwin-specific nuances, like .lnk pathname conversions. We'd like to
keep the solution as close to the problem as possible, which would be in
the kernel module. Given this, since Win32 apps don't really go through
cygwin to access our file system (it appears as a network drive), we
need to be able create that local .lnk file that will be interpreted
correctly by Windows and cygwin.
Adam
--
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/
- Raw text -