19 messages in net.java.dev.jna.usersRe: [jna-users] Re: Identifying symb...
FromSent OnAttachments
Timothy WallDec 11, 2007 5:34 am 
Normen MüllerDec 11, 2007 6:35 am 
Normen MüllerDec 11, 2007 6:52 am 
Timothy WallDec 11, 2007 7:20 am 
Timothy WallDec 11, 2007 7:53 am 
Timothy WallDec 11, 2007 7:55 am 
Nikolas LotzDec 11, 2007 8:05 am 
Normen MüllerDec 11, 2007 8:27 am 
Normen MüllerDec 11, 2007 8:37 am 
Timothy WallDec 11, 2007 10:25 am 
Duncan McGregorDec 11, 2007 3:05 pm 
Normen MüllerDec 12, 2007 12:04 am 
Peter ReillyDec 12, 2007 1:34 am 
Normen MüllerDec 12, 2007 1:39 am 
Timothy WallDec 12, 2007 4:34 am 
Timothy WallDec 12, 2007 4:38 am 
Normen MüllerDec 12, 2007 4:57 am 
Normen MüllerDec 12, 2007 5:04 am 
Timothy WallDec 12, 2007 5:36 am 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: [jna-users] Re: Identifying symbolic links on Mac OSX 10.5.1Actions...
From:Timothy Wall (twal@dev.java.net)
Date:Dec 11, 2007 7:53:28 am
List:net.java.dev.jna.users

On Dec 11, 2007, at 9:35 AM, Normen Müller wrote:

Timothy Wall <twalljava@...> writes:

Several things to look at: 1) how is the C library loaded? is it loaded properly on OSX (i.e. do you get an instance of ISVNCLibrary)?

Yes, I think so. In debug mode the debugger outputs

Proxy interface to Native Library </usr/lib/libc.dylib@2414037576>

when I click on cLibrary in the line

ISVNCLibrary cLibrary = JNALibraryLoader.getCLibrary();

So you know the library lookup and load works. Good.

2) how is lstat defined on OSX 10.5.1? in glibc, it is a macro that points to _xstat

I have no clue about the definition of lstat on OSX 10.5.1, guess that's the real problem. I was hoping the SVNKit guys already did it right ;-)

A quick look at sys/stat.h shows a single declaration of lstat. If you don't get an UnsatisfiedLinkError when that method is invoked, then that symbol exists in the library. Also good.

I would recommend writing a small unit test program that reproduces the SVNKit code, then you can instrument it as needed to figure out where it is failing.

That's, what I am doing. Currently I am not using the whole SVNKit library but just testing this SVNLinuxUtil class:

synchronized (ourSharedMemory) { ourSharedMemory.clear(); int rc; synchronized (cLibrary) { rc = SVNFileUtil.isOSX || SVNFileUtil.isBSD ? cLibrary.lstat(path, ourSharedMemory) : cLibrary.__lxstat64(0, path, ourSharedMemory); }

Check the return code here. Does it indicate an error?

if (rc < 0) { if (file.exists() || file.isDirectory() || file.isFile()) { return null; } return SVNFileType.NONE; } int mode = SVNFileUtil.isOSX || SVNFileUtil.isBSD ? ourSharedMemory.getInt(8) : ourSharedMemory.getInt(16);

Here's where you might get into trouble. SVNKit is just grabbing memory offsets from the stat structure (typically you'd probably want to define a structure representing the native structure, but in this case SVNKit is doing some quick and dirty lookups to get just what they need).

The required offset depends on where the "mode_t st_mode" field shows up in the "stat" structure (see sys/stat.h). On darwin/bsd, the first two fields are 32 bits each, which gives you the 8 byte offset. This looks correct.

int type = mode & 0170000; if (type == 0120000) { return SVNFileType.SYMLINK; } else if (type == 0040000) { return SVNFileType.DIRECTORY; } else if (type == 0100000) { return SVNFileType.FILE; } else { if (file.exists() || file.isDirectory() || file.isFile()) { return null; } return SVNFileType.NONE; }

Print out the actual mode read from memory, and double check the predefined constants to ensure they match the header file definitions.

At what point is the function returning "null"? Does it work for FILE? does it work for DIRECTORY? does it work for SYMLINK?