cygwin, Coda and symbolic links
Hello cygwin mailing list, I'm a new subscriber looking to get some information relevant to the Coda File System development at Carnegie Mellon University, which uses cygwin as a platform to run on Windows 2000/WinXP. We rely heavily on symbolic links for a number of different features, most significantly representing conflicts within the file system. Conflicts are inconsistent file system objects which are represented as "dangling" or "broken" symlinks pointing to the file identifier of the inconsistent object, e.g., if "foo" fell into conflict: [host]# ls -l foo lr--r--r-- 1 root nfsnobody [date/time] foo -> @[EMAIL PROTECTED] Coda's current symlink support in cygwin is nonexistent, but we are looking to support symlinks in the same manner cygwin appears to -- as special Windows shortcuts that cygwin can interpret as symlinks. Allowing cygwin to see our conflicts as broken symlinks would be a big win for our repair mechanisms. We looked at the internals of a Windows .lnk shortcut file and (of course) part appears binary; we assume somewhere along the line that the cygwin developers reverse-engineered the contents of these files to hijack them for their own purposes. First question, I've hunted for this information around the website, in the past mailing-list archives and the web, and it doesn't appear readily available. Is there anyone on the list who knows more about the internals of Windows shortcuts and could clue the Coda developers in? Also, how these shortcuts should be crafted to appear as symlinks to cygwin? We already know that they must be read-only files from Windows' perspective, and cygwin appears to use the "comment" field under Properties for its own addressing. Secondly, is there a more appropriate mailing list for this question? (maybe the developers' list?) Any information is appreciated, as well as a reply-all on any replies. Thanks! Adam Wolbach -- 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/
Re: cygwin, Coda and symbolic links
http://www.google.com/search?as_q=windows+shortcut+file+format The first match http://mediasrv.ns.ac.yu/extra/fileformat/windows/lnk/shortcut.pdf is what you're looking for and what I used when implementing the shortcut stuff. Thanks, this gets me more than halfway to what I need to know -- the missing piece is how these fields need to be filled out to appear as a symbolic link to cygwin. Worst case I can just hunt through the cygwin source, but if you happen to know or have notes lying around somewhere, it might be useful to more than just us to post them somewhere. Thanks again. Adam Wolbach -- 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/
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/
