This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cygwin, Coda and symbolic links



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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]