JNI/Linux/chown

[GfxGuy]

I've been getting the dreaded and oft discussed
"java.lang.UnsatisfiedLinkError" exception...

---------
The Java:
---------

public class MyJNI
{
static
{
System.loadLibrary("MyJNI");
}

public native boolean chown(String filename, int user);
}

--------
The C++:
--------

#include "MyJNI.h"
#include <sys/types.h>
#include <unistd.h>

JNIEXPORT jboolean JNICALL Java_MyJNI_chown (JNIEnv *env, jobject jobj,
jstring fname, jint fowner)
{
jboolean rval = JNI_FALSE;
jboolean iscopy;
const char *name;
int owner = fowner;

name = env->GetStringUTFChars(fname, &iscopy);

if(chown(name,owner,owner) == 0) rval = JNI_TRUE;

env->ReleaseStringChars(fname, (jchar *) name);

return rval;
}

-----------
The problem
-----------

The System.loadlibrary function works just fine - libMyJNI.so is indeed
there and in the ld_library_path (I know this because I had to work
through all of that, too). It says it can't find "chown", the specific
function:

java.lang.UnsatisfiedLinkError: chown
at com.turner.utilities.MyJNI.chown(Native Method)
at com.turner.utilities.MyUtils.chown(Unknown Source)
..
..
..

MyUtils.chown is just another wrapper on top so that other higher level
classes don't have to care about the JNI aspect of it.

I haven't programmed in C/C++ in a long time... mostly written in Java
and other scripting languages for the past few years, I just needed a
way to "chown" files. My HelloWorld test worked just fine with the
same compiler and linker options:

INC= -I${JAVA_HOME}/include \
-I${JAVA_HOME}/include/linux

gcc -c ${INC} -fPIC -g MyJNI.c++
gcc -shared -W1 -lstdc++ -o libMyJNI.so MyJNI.o

TIA for any advice on either this specific problem, or if you could
point me to something that exists to perform chown, that'd be cool...

 

[Lucy]

.> TIA for any advice on either this specific problem, or if you could

point me to something that exists to perform chown, that'd be cool...

1. maybe you need to give it the full path to the file not just the name of
the file

2. or you could just run it as a command

 

[Gordon Beaton]

I've been getting the dreaded and oft discussed
"java.lang.UnsatisfiedLinkError" exception...

java.lang.UnsatisfiedLinkError: chown
at com.turner.utilities.MyJNI.chown(Native Method)

You've got a package declaration in your Java class, but you didn't
generate the native hewader using the same fully qualified classname.
You must include the package name when you run javah or it won't
generate the correct native symbol names.

BTW there's nothing remotely "++" about the C method you've posted. I
don't see why you've named it .c++ and link with libstdc++.

Also, add -D_REENTRANT to your CFLAGS.

/gordon

 

[Ross Bamford]

I've been getting the dreaded and oft discussed
"java.lang.UnsatisfiedLinkError" exception...

[snip voodoo]

TIA for any advice on either this specific problem, or if you could
point me to something that exists to perform chown, that'd be cool...

Perhaps your purpose is to play with JNI? In that case, ignore this.
Otherwise:

public class Cot {
private static final String CHOWN_COMMAND = "chown you:group file";
public static void main(String[] args) {
try {
Process chown = Runtime.getRuntime().exec(CHOWN_COMMAND);
chown.waitFor();
System.out.println("Success: "+(chown.exitValue() == 0));
} catch (Exception e) {
System.out.println("Exception: "+e);
}
}
}

Saves a lot of messing about...

 

[GfxGuy]

Actually, there is... I know the file operations are C, but the access
to "env" is handled a differently. I know it's only a minor detail,
but I like it that way better.

When I tested my JNI HelloWorld, it would not work (again, got the
UnsatisfiedLinkError) when I did not use libstdc++, a problem (and
solution) that I found on this newsgroup.

 

[GfxGuy]

Yes and no... if I want to make it portable, the idea is that only a
small amount of native code would have to be rewritten and it would
integrate better with each OS. I guess this could be packed off in
some class that would have to be rewritten, too. Just seems to me
there is a right way and a quick and easy way, they are not the same
this time.

Seeing as how I do need it quickly, though, and I'm not having much
success with JNI, that I'll end up doing it this way now. Luckily, in
an apparently strange twist of fate, we are actually (painfully slowly)
replacing Windows boxes with Linux boxes.

 

[Ross Bamford]

Yes and no... if I want to make it portable, the idea is that only a
small amount of native code would have to be rewritten and it would
integrate better with each OS. I guess this could be packed off in
some class that would have to be rewritten, too. Just seems to me
there is a right way and a quick and easy way, they are not the same
this time.

Trust me, this is /a/ right way. JNI is /not/ a right way to do this.
It's not really the right way to do anything, IMHO, but especially not
simple stuff like this. There are already myriad ways that one program
can talk to another, VM or no.

Seeing as how I do need it quickly, though, and I'm not having much
success with JNI, that I'll end up doing it this way now. Luckily, in
an apparently strange twist of fate, we are actually (painfully slowly)
replacing Windows boxes with Linux boxes.

Does windows even have file ownership?

Also seems to me that if you are going to a system without a chown
binary, then you need to just write one. You still end up with a small
bit of native code, but probably only a one-liner that compiles without
the JNI libs.