All Forums |
Register |
Login |
Search |
Subscriptions |
My Profile |
Inbox |
Tool Warehouse |
FAQs |
Resources |
Help |
Member List |
Address Book |
Logout |
|
|
Does mixed-mode work the other way?
|
Logged in as: Guest |
Users viewing this topic: none |
|
Login |
|
|
Does mixed-mode work the other way? - Apr. 21, '06, 4:56:17 PM
|
|
|
woehlkmp
Posts: 102
Status: offline
|
Before I go do a whole bunch of research that may dead-end, I thought I'd ask if anyone else already knows something...
I would like to write a DLL that is able to do the following:
- Read and set NFS (POSIX-style) permissions on NFS-mounted network volumes
- Read and create Interix-style symlinks on both NFS volumes and the regular (NTFS) volumes
Both of these should take Windows paths. I want to say (1) is do-able, because Explorer already has this ability. Also, at least the 'read' part of the second half of (2) should be do-able because I can see with an editor that does NOT understand them that they seem to be pretty simple; some extra data and the link path in UNICODE, apparently, which I could easily parse with fopen(), etc.
Does anyone out there have any existing knowledge?
|
|
|
RE: Does mixed-mode work the other way? - Apr. 23, '06, 8:34:37 AM
|
|
|
jerker_back
Posts: 68
Joined: Jul. 7, '05,
From: Sweden
Status: offline
|
quote:
some extra data and the link path in UNICODE
Interesting - I didn't realize it is a UNICODE file
Looking at the X11 symlink in /usr/lib and the bin symlink in /usr with a HEX-editor the content is:
IntxLNK[0x01] . . / X 1 1 R 6 / l i b
IntxLNK[0x01] . . / b i n
So, the format begins with IntxLNK + 0x01 (SOH - start of heading) followed by the the Interix-path in UNICODE.
The Interix SDK does not give you much help other then create new links, right?
To build your own link handler should be pretty easy though.
I would do like this:
* Filter all files but files with system attribute and no extensions.
* check file for IntxLNK signature and if match, read content in a wide char buffer
* translate Interix path to Windows path (keep the wide char for better performance)
* handle the file or directory using the WIN32 base API functions (I would NOT use the more limited CRT-functions)
|
|
|
RE: Does mixed-mode work the other way? - Apr. 23, '06, 9:27:03 AM
|
|
|
jerker_back
Posts: 68
Joined: Jul. 7, '05,
From: Sweden
Status: offline
|
I found this: special files on Services for Unix (SFU) / Interix
|
|
|
RE: Does mixed-mode work the other way? - Apr. 24, '06, 10:40:05 AM
|
|
|
woehlkmp
Posts: 102
Status: offline
|
quote:
The Interix SDK does not give you much help other then create new links, right?
To build your own link handler should be pretty easy though.
Nope, getting those to work is peanuts... it's getting NFS symlinks working that I'm more interested in. I don't know of any way to do that without linking to Interix API's (unless SUA intruduced some Windows API's I don't know about). In fact, using Interix for permissions is probably safer as well, because the API's are defined by POSIX and not buried in some obscure Windows library where they might be changed without notice (i.e. the ones Explorer is using).
I thought of one possible kluge that might work; can I write an Interix DLL and dynamically load it (and makes calls into it) from a Win32 dll? It's an extra library, but I've been thinking about it, and think that may actually be a better solution anyway.
|
|
|
RE: Does mixed-mode work the other way? - Apr. 24, '06, 1:04:23 PM
|
|
|
Rodney
Posts: 3695
Joined: Jul. 9, '02,
From: /Tools lab
Status: online
|
Each process can "talk" with either the kernel directly or it's
subsystem. The "mixed mode" binaries are special because additional
work has happened to allow a Win32 process talk with the Interix
subsystem. So the best chance you have is a mixed mode program.
|
|
|
RE: Does mixed-mode work the other way? - Apr. 24, '06, 4:05:23 PM
|
|
|
jerker_back
Posts: 68
Joined: Jul. 7, '05,
From: Sweden
Status: offline
|
quote:
NFS symlinks
Sorry, I'm a little bit confused - partly reffering to another post - you are on a corporate unix NFS network, using several machines with different OS's and trying to maintain a single home on a NFS share (or mount if you so will). I don't know if I dare asking about this but ... are these links handled by the server? How are you supposed to handle them from a Windows workstation? Why are you seeing them as links and not as the objects linked to anyway? How do your unix workstation handle the links?
|
|
|
RE: Does mixed-mode work the other way? - Apr. 24, '06, 4:15:57 PM
|
|
|
woehlkmp
Posts: 102
Status: offline
|
quote:
Sorry, I'm a little bit confused
I am confused by your confusion, so I guess that makes us even.
quote:
you are on a corporate unix NFS network, using several machines with different OS's and trying to maintain a single home on a NFS share (or mount if you so will).
Correct. However I don't see what that has to do with this post.
quote:
I don't know if I dare asking about this but ... are these links handled by the server? How are you supposed to handle them from a Windows workstation? Why are you seeing them as links and not as the objects linked to anyway? How do your unix workstation handle the links?
NFS is running on FreeBSD. Because the underlying FS is POSIX, the links are fine on any non-Windows box, and under Interix on Windows. Under normal Windows they are "invisible" (i.e. they act like hardlinks; Windows sees the file/directory but doesn't know it's a link). I am trying to write a non-Interix DLL that a: is able to identify them as symlinks and determine the link path, and b: is able to create actual symlinks. Also, I want to be able to read/write the NFS (i.e. real) permissions. In order to do this, I am fine with writing a second DLL that is Interix-based, so long as the first one can talk to it (in fact, I would prefer this solution as it means the first one is not dependent on Interix; i.e. it can still execute with fallbacks if the Interix DLL can't load).
|
|
|
RE: Does mixed-mode work the other way? - Apr. 24, '06, 6:45:39 PM
|
|
|
jerker_back
Posts: 68
Joined: Jul. 7, '05,
From: Sweden
Status: offline
|
quote:
links are fine ... under Interix on Windows
Really, Interix understand them? And Windows Explorer can read all files and directories but doesn't understand the links - just as the case under NTFS. I'm not sure, but I think you need to look at the "Microsoft Services for NFS" - did you install a file system driver for NFS (very likely)? If so, is there any exports you can see in that driver? Or, maybe you can find exports in some of the NFS system DLLs. Since Interix can read the links, there's no need to write your own handler - just implement a shell extension DLL with the exports you find. If you can't find any exports, there's some examples how such a network file system driver is made - but that's really a time consuming task.
As a perspective, there is some drivers for the ext2 file system for Windows NT (ie Paragon and Stephan Schreiber's excellent Ext2 IFS For Windows. I have a dual boot with Fedora 5 and using Stephan's driver I can read and write onto Fedoras ext3 volumes from Windows R2. None of these drivers handles ext2 symlinks however. It took him 3 years full time to write the driver (thesis project).
|
|
|
RE: Does mixed-mode work the other way? - Apr. 24, '06, 8:11:26 PM
|
|
|
woehlkmp
Posts: 102
Status: offline
|
quote:
And Windows Explorer can read all files and directories but doesn't understand the links - just as the case under NTFS.
Eh? Windows does not understand Interix symlinks... however Interix does not make "Interix" symlinks on an NFS drive, it makes real ones (at least if the NFS server has a POSIX file system backing the share). Thus, something fundamentally different is going on when making local "symlinks" vs. "symlinks" on an NFS mount. Maybe if the server is also SFU/SUA, they look like Interix links locally, but I would expect they are exported the same to a client; thus they would be invisible (act like hardlinks) to a Windows NFS client.
Maybe that's what you said, but I wasn't sure.
quote:
Since Interix can read the links, there's no need to write your own handler - just implement a shell extension DLL with the exports you find.
Duh! You're right; most likely the Interix subsystem is just making use of additional calls to the NFS driver that aren't used for plan-old Windows (or are used, but differently). Also, that (slightly) increases the chances of the API being stable (but it wouldn't surprise me in the least if it isn't).
I'm not going to touch writing a driver, though; I'd rather route calls through Interix. If I can't do that, I'll give up.
|
|
|
RE: Does mixed-mode work the other way? - Apr. 25, '06, 7:37:28 AM
|
|
|
jerker_back
Posts: 68
Joined: Jul. 7, '05,
From: Sweden
Status: offline
|
I thought about this a while - I think it is strange that Interix can understand the links but Windows Explorer can not. Unless it's an undocumented Interix specific ability to somehow read generic unix symlinks? What about a NT Console Window - how do the links look there?
I got curious so I looked and expanded the NFS files from CD. msnfsflt.sys seems to be the NFS file system filter driver. rpcxdr.sys is probably the NFS network handler. It looks like the NFS implementation is entirely in WIN32 and have nothing to do with Interix (is Interix needed for NFS installation?). Some of the system DLLs are COM libraries and some are using MFC - probably for admin utilities. It seems also that MS have already made a shell extension for NFS: nfssprop.dll - allow mounting etc inside Windows Explorer (can you do that?). I think you need access to the MS NFS API to be successful - or - in case Interix have some specific implementations, track them down (see how Interix is interfacing the MS NFS API) and implement a new shell extension. I don't think you can use Interix to do that - even if a mixed mode shell extension would really cool!
|
|
|
RE: Does mixed-mode work the other way? - Apr. 25, '06, 10:20:08 AM
|
|
|
woehlkmp
Posts: 102
Status: offline
|
quote:
I think it is strange that Interix can understand the links but Windows Explorer can not.
I don't think that's true. Windows in general doesn't have a comparable concept of a "symlink"; what would it do with them? My suspicion is that it does know it's a symlink, but the decision was made to redirect symlinks to their targets so that other applications wouldn't panic (remember, Explorer would have to be modified to display them). The nfssprop is an exception because a: it's a "hook" that Explorer was designed to handle, and b: it is presenting information to the user, not to the system, and therefore can tell you 'what's really there' (although it's odd that this doesn't show symlinks, but it may be injected after the aforementioned redirection).
At any rate, Interix certainly recognizes symlinks correctly, so at some level the NFS driver is definately making this information available.
|
|
|
RE: Does mixed-mode work the other way? - Apr. 25, '06, 10:45:23 AM
|
|
|
jerker_back
Posts: 68
Joined: Jul. 7, '05,
From: Sweden
Status: offline
|
quote:
At any rate, Interix certainly recognizes symlinks correctly, so at some level the NFS driver is definately making this information available.
So, you are convinced that it is the NFS API who interprets the links - OK - then it is just to figure out how and what Interix is interfacing.
Test the NT Console Window - you might find that the file system driver is exposing full functionality (which is logical), it is just that Windows Explorer doesn't recognize the type (analogical to junctions and other special files on NTFS). Then the task would be much more simpler.
|
|
|
RE: Does mixed-mode work the other way? - Apr. 25, '06, 11:26:29 AM
|
|
|
woehlkmp
Posts: 102
Status: offline
|
quote:
So, you are convinced that it is the NFS API who interprets the links
No, I'm just guessing, since the alternative is that Interix has a totally seperate NFS driver. However, this does seem unlikely.
quote:
Test the NT Console Window
I'm not sure what you mean by this. I tried 'ls -l' in cmd.exe. This showed symlinks (as expected, since it's calling the Interix 'ls'). 'dir' did not, but I would imagine for the same reason Explorer doesn't; SUA would have to replace 'dir.exe' for this to happen.
I don't think there is any way to verify functionality outside of calling into the NFS driver directly. Eventually, I plan to try that, but I have (ahem) "real work" to do ATM .
|
|
|
New Messages |
No New Messages |
Hot Topic w/ New Messages |
Hot Topic w/o New Messages |
|
Locked w/ New Messages |
Locked w/o New Messages |
|
Post New Thread
Reply to Message
Post New Poll
Submit Vote
Delete My Own Post
Delete My Own Thread
Rate Posts |
|
|
|