I'm looking for a code fragment, using which I must be to change the file permissions on unix. My project runs on java 1.4.2 ..
just a sample code example or methods which needs to be used will do..
Regards,
Senny
You're not the only one:
How to change the file's permission and last modified in Java?
You could, in principle, use Runtime.exec("chmod ...") if the existing java.io.File methods aren't enough. But it wouldn't be portable.
You could also look at the Gnu ClassPath implementation of java.lang.File
They implemented the function based on JNI calls:
native/jni/java-io/java_io_VMFile.c:
set_file_permissions: new helper function.
Java_java_io_VMFile_setReadable: new native method to bakcup 1.6 methods
in VMFile.java.
VMFile.java declares the call:
/**
* Set the write permission of the file.
*/
public static synchronized native boolean setWritable(String path,
boolean writable,
boolean ownerOnly);
native/jni/java-io/java_io_VMFile.c does implement the desired function...
JNIEXPORT jboolean JNICALL
Java_java_io_VMFile_setWritable (JNIEnv *env,
jclass clazz __attribute__ ((__unused__)),
jstring name,
jboolean writable,
jboolean ownerOnly)
{
return set_file_permissions (env, name, writable, ownerOnly,
CPFILE_FLAG_WRITE);
}
[...]
result = cpio_chmod (filename, permissions);
So... if you really want it, it is possible to implement it, by looking at the source of cpio.c: it calls chmod from libc standard library (LibGW32C does port some of those functions to Windows)
Just to be extra clear: Java 1.6 introduces getters/setters like File.canExecute() and File.setExecutable(boolean) for file permissions. So one solution is to use the latest JDK instead of the 1.4 you mentioned. Otherwise, as suggested, you can try to backport, or call out to platform-specific commands.
Related
I am reading several articles on mocking C functions (like CMock, or CMocka), but I am not sure how the actual functions are replaced with mocked functions in this process. For example, CMocka relies on automatic wrapping using a GNU compiler, which supports parameters like --wrap to append the __wrap prefix to function calls, or weak symbols which allow you to override any symbol you like.
But how do you do this in Visual Studio, for pretty much all other frameworks?
For example, CMock has an example similar to this (simplified a lot here):
// myfunc.c
#include <parsestuff.h>
// this is the function we would like to test
int MyFunc(char* Command)
{
// this is the call to the function we will mock
return ParseStuff(Command);
}
There is also the actual implementation, which contains the actual function the linker should find in the actual application:
// parsestuff.c
int ParseStuff(char* cmd)
{
// do some actual work
return 42;
}
Now, during testing the Ruby script creates mock functions like:
// MockParseStuff.c (auto created by cmock)
int ParseStuff(char* Cmd);
void ParseStuff_ExpectAndReturn(char* Cmd, int toReturn);
But if the VS project already includes parsestuff.c, how will it be possible that the call from myfunc.c ends up in MockParseStuff.c?
Does this mean I cannot have parsestuff.c included in the unit testing project? But if this is the case, then it's also impossible to mock, for example, MyFunc from myfunc.c in any tests, since I already had to include the file it in order to test it?
(Update) I am also aware that I can include the .c file instead of the .h file, and then do some preprocessor stuff to replace the original call, like:
// replace ParseStuff with ParseStuff_wrap
#define ParseStuff ParseStuff_wrap
// include the source instead of the header
#include <myfunc.c>
#undef ParseStuff
int ParseStuff_wrap(char* cmd)
{
// this will get called from MyFunc,
// which is now statically included
}
but this seems like a lot of plumbing, and I don't even see it mentioned anywhere.
Here's a simple and short solution with hippomocks:
I created an empty Win32 console application with
main.cpp
myfunc.c + myfunc.h
parsestuff.c, parsestuff.h
and added the code from your example.
With help of hippomocks, you can mock every C-Function. Here's how my main.cpp looks like:
#include "stdafx.h"
#include "myfunc.h"
#include "hippomocks.h"
extern "C" int ParseStuff(char* cmd);
int _tmain(int argc, _TCHAR* argv[])
{
MockRepository mocks;
mocks.ExpectCallFunc(ParseStuff).Return(4711);
char buf[10] = "";
int result = MyFunc(buf);
return result; //assert result is 4711
}
HippoMocks is a free, simple and very powerful one-header framework and can be downloaded on GitHub.
Hope I've earned the bounty :)
UPDATE, How it works:
HippoMocks gets the func pointer to ParseStuff
HippoMocks builds a replacement func pointer to a template function with same signature and own implementation.
Hippomocks patches the jmp opcode from the function call prologue in memory, so that it points to the replaced function.
Replacement and memory patch are released after call or in destructor.
Here's how it looks like on my machine:
#ILT+3080(_ParseStuff):
00D21C0D jmp HippoMocks::mockFuncs<char,int>::static_expectation1<0,char *> (0D21DB1h)
If you watch the memory address 00D21C0D (may differ from run to run) in memory window, you will see, that it gets patched after the call of ExpectCallFunc.
I have not dealt with the C mocking libraries or Visual Studio, but I have thought about this in my own project. The Feathers book suggests the preprocessor seam or the link seam as a tool for dealing with this. You already mentioned the preprocessor seam, so I'll focus on the link seam.
The link seam requires the mocked function to be in a library, and the mock function to be in a library. The test can link against the mock function library while the target application can link against the original library.
Of course, as you mention, to mock MyFunc() you will have to create another library and a separate test application to link against it (or dynamically load and unload libraries in the test application).
It sounds quite laborious which is why I am procrastinating adding tests in my own application!
Hope this helps!
I have a sandboxed Cocoa app that, during an export process, needs to run a third party command-line tool. This tool appears to be hardcoded to use /tmp for its temporary files; sandboxing doesn't permit access to this folder, so the export fails.
How can I get this tool to run? I don't have access to its source code, so I can't modify it to use NSTemporaryDirectory(), and it doesn't appear to respect the TMP or TEMPDIR environment variables. For reasons I don't understand, giving myself a com.apple.security.temporary-exception.files.absolute-path.read-write entitlement doesn't seem to work, either.
Is there some way to re-map folders within my sandbox? Is there some obscure trick I can use? Should I try to patch the tool's binary somehow? I'm at my wit's end here.
I was able to get user3159253's DYLD_INSERT_LIBRARIES approach to work. I'm hoping they will write an answer describing how that works, so I'll leave the details of that out and explain the parts that ended up being specific to this case.
Thanks to LLDB, elbow grease, and not a little help from Hopper, I was able to determine that the third-party tool used mkstemp() to generate its temporary file names, and some calls (not all) used a fixed template starting with /tmp. I then wrote a libtmphack.dylib that intercepted calls to mkstemp() and modified the parameters before calling the standard library version.
Since mkstemp() takes a pointer to a preallocated buffer, I didn't feel like I could rewrite a path starting with a short string like "/tmp" to the very long string needed to get to the Caches folder inside the sandbox. Instead, I opted to create a symlink to it called "$tmp" in the current working directory. This could break if the tool chdir()'d at an inopportune time, but fortunately it doesn't seem to do that.
Here's my code:
//
// libtmphack.c
// Typesetter
//
// Created by Brent Royal-Gordon on 8/27/14.
// Copyright (c) 2014 Groundbreaking Software. This file is MIT licensed.
//
#include "libtmphack.h"
#include <dlfcn.h>
#include <stdlib.h>
#include <unistd.h>
//#include <errno.h>
#include <string.h>
static int gbs_has_prefix(char * needle, char * haystack) {
return strncmp(needle, haystack, strlen(needle)) == 0;
}
int mkstemp(char *template) {
static int (*original_mkstemp)(char * template) = NULL;
if(!original_mkstemp) {
original_mkstemp = dlsym(RTLD_NEXT, "mkstemp");
}
if(gbs_has_prefix("/tmp", template)) {
printf("libtmphack: rewrote mkstemp(\"%s\") ", template);
template[0] = '$';
printf("to mkstemp(\"%s\")\n", template);
// If this isn't successful, we'll presume it's because it's already been made
symlink(getenv("TEMP"), "$tmp");
int ret = original_mkstemp(template);
// Can't do this, the caller needs to be able to open the file
// int retErrno = errno;
// unlink("$tmp");
// errno = retErrno;
return ret;
}
else {
printf("libtmphack: OK with mkstemp(\"%s\")\n", template);
return original_mkstemp(template);
}
}
Very quick and dirty, but it works like a charm.
Since #BrentRoyal-Gordon has already published a working solution I'm simply duplicating my comment which inspired him to produce the solution:
In order to fix a program behavior, I would intercept and override some system calls with the help of DYLD_INSERT_LIBRARIES and a custom shared library with a custom implementation of the given system calls.
The exact list of the syscalls which need to be overridden depends on nature of the application and can be studied with a number of tools built upon MacOS DTrace kernel facility. E.g. dtruss or Hopper. #BrentRoyal-Gordon has investigated that the app can be fixed solely with an /appropriate/ implementation of mkstemp.
That's it. I'm still not sure that I've deserved the bounty :)
Another solution would be to use chroot within the child process (or posix_spawn options) to change its root directory to a directory that is within your sandbox. Its “/tmp” will then be a “tmp” directory within that directory.
I have the following use case which I had previously solved in Java, but am now required to port the program to C.
I had a method A which called a method do_work() belonging to an abstract class Engine. Each concrete implementation of the class was constructed as follows:
users would submit the definition of the do_work() method . If this definition was correct, the programmer would construct a concrete implementation of the Engine class using the Java Compiler API. (code for this is included for reference below).
How can I do something similar in C:
I now have a structure Engine, with a function pointer to the do_work() method. I want users to be able to submit this method at run time (note: this only occurs once, on startup, once the Engine structure has been constructed, I do not want to change it) via command line.
How could I go about this? I've read around suggestions stating that I would have to use assembly to do this, others stating that this was not possible, but none of them giving a good explanation or references. Any help would be appreciated.
The solution doesn't need to be compatible with 32/64 bits machines, as the program this is written for is only for 64 bits machines.
For reference, the Java Code:
JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();
StandardJavaFileManager stdFileManager = compiler
.getStandardFileManager(null, Locale.getDefault(), null);
Iterable<? extends JavaFileObject> compilationUnits = null;
String[] compileOptions = new String[] { "-d", "bin" };
Iterable<String> compilationOptions = Arrays.asList(compileOptions);
SimpleJavaFileObject fileObject = new DynamicJavaSourceCodeObject(
"package.adress",getCode());
JavaFileObject javaFileObjects[] = new JavaFileObject[] { fileObject };
compilationUnits = Arrays.asList(javaFileObjects);
}
DiagnosticCollector<JavaFileObject> diagnostics = new DiagnosticCollector<JavaFileObject>();
CompilationTask compilerTask = compiler.getTask(null, stdFileManager,
diagnostics, compilationOptions, null, compilationUnits);
boolean status = compilerTask.call();
if (!status) {// If compilation error occurs
/* Iterate through each compilation problem and print it */
String result = "";
for (Diagnostic diagnostic : diagnostics.getDiagnostics()) {
result = String.format("Error on line %d in %s",
diagnostic.getLineNumber(), diagnostic);
}
Exception e = new Exception(result);
throw e;
}
stdFileManager.close();// Close the file manager
/*
* Assuming that the Policy has been successfully compiled, create a new
* instance
*/
Class newEngine = Class
.forName("package.name");
Constructor[] constructor = newPolicy.getConstructors();
constructor[0].setAccessible(true);
etc.
}
In C all code must be compiled to native one before usage, so the only way for you is to use command line compiler to build code submitted by users. It may be GNU C++ compiler for example, or Visual C++ compiler (but for Visual C++ I don't know what about legal problems, is it permitted by license to do that).
So, first of all, select your compiler, probably GNU one.
Next, you can compile it as executable program or as DLL (assuming your software is for
Windows). If you decide to compile it to DLL, you have to use Win32 function LoadLibrary to load new built DLL into your process, and after that you can use GetProcAddress function to get method address and call it dynamically from C++ (you must implement a function wrapper and make it public in DLL).
If you decide to compile it as EXE file, you have to use CreateProcess function to run your code, send parameters via command line and receive data, may be, with pipe (see CreatePipe function), or may be with temporary file, or any other interprocess communication way available in Windows.
I think in your situation it is better to compile to EXE file, because in DLL if user code is buggy your main program may crash.
I've an executable hosting tcl interpretor, and a library hosting a extension.
I want to be able to build the library dynamically (loaded with Tcl's load)
or statically (single executable, or so loaded implicitly).
The Executable code:
#ifdef GO_STATIC
extern int My_ext_Init(Tcl_Interp* interp);
Tcl_StaticPackage(interp, "my_ext", My_ext_Init, My_ext_Init);
My_ext_Init(interp); // THIS SHOULD NOT BE NEEDED !!
Tcl_SetVariable(interp, "is_statically_linked", "1", TCL_GLOBAL_ONLY);
#else
Tcl_SetVariable(interp, "is_statically_linked", "0", TCL_GLOBAL_ONLY);
#endif
The library Code .. can be static or dynamic library ( .a or .so / .lib or .dll ):
int My_ext_Init(Tcl_Interp *interp)
{
if (Tcl_PkgProvide(interp, "My_ext", "1.0") == TCL_ERROR) {
return TCL_ERROR;
}
Tcl_CreateObjCommand(interp, /*...etc...*/);
}
The startup tcl code:
global is_statically_linked
if {$is_statically_linked} {
load {} my_ext
} else {
load my_ext my_ext
}
The problem is .. I really shouldn't be calling My_ext_Init(interp); as it
should called by Tcl when I evaluate load {} my_ext
Made community wiki so that the recommended way can be put here.
Registering a “static package” is done in your application init routine, and should be done after the main interpreter is created (but obviously before you start running your scripts in it). It's a mechanism that's really designed to work the “Big Wish” method of program building, when you use Tcl_Main() to do the work of making an interpreter. When you're doing that, there's a callback into your code (typically called Tcl_AppInit though the name is actually arbitrary) that you can specify and which is the ideal place to put calls to Tcl_StaticPackage. The callback will be called at the right point for you to do the static package registration.
However, that's all considered rather old hat these days. A far better method is to always use dynamic libraries and to instead package everything together as a starkit or starpack. The advantage with doing that is that you just need to build your .so files as stub-enabled (strongly recommended anyway) packages and then you include them in your VFS during the packaging process. After that, you can just do package require and it will all work. (Or you can locate the shared libraries in the virtual mount when running and load them directly.) What's even better is that you can deliver a single .kit file that supports multiple platforms; starpacked executables can't be quite that flexible though, as there are some natural restrictions on portability of binary executables. :-)
I'd like to hack on an existing GLib based C project using Vala.
Basically what I'm doing is, at the beginning of my build process, using valac to generate .c and .h files from my .vala files and then just compiling the generated files the way I would any .c or .h file.
This is probably not the best way, but seems to be working alright for the most part.
My problem is that I'm having a hard time accessing my existing C code from my Vala code. Is there an easy way to do this?
I've tried writing my own .vapi files (I didn't have any luck with the tool that came with vala), but I can't find any decent documentation on how to write these.
Does any exist? Do I need one of these files to call existing C code?
Yes, to call a C function, you need to write a binding for it. The process is described in http://live.gnome.org/Vala/Tutorial#Binding_Libraries_with_VAPI_Files, however, this doesn't apply directly to custom functions or libraries written without GObject. You'll probably need help from #vala IRC channel if you have complex binding for non-GObject libraries.
However, most of the time, we use simple vapi files to bind some autoconf define or some functions written in plain C, for efficiency reason or broken vala, or whatever other reason. And this is the way that most people do:
myfunc.vapi
[CCode (cheader_filename = "myfunc.h")]
namespace MyFunc {
[CCode (cname = "my_func_foo")]
public string foo (int bar, Object? o = null);
}
myfunc.h (and corresponding implementation in a .c linked with your project)
#include <glib-object.h>
char* my_func_foo(int bar, GObject* o)
example.vala could be
using MyFunc;
void main() {
baz = foo(42);
}
When compiling with valac, use --vapidir= to give the directory location of the myfunc.vapi. Depending on your build system, you may need to pass extra argument to valac or gcc CFLAGS in order to link everything together.
The only addition I would make to elmarco's answer is the extern keyword. If you're trying to access a single C function that's already available in one of your packages or the standard C/Posix libraries, you can access it easily this way.
For GLib-based libraries written in C you can try to generate gir-files from your C-sources: Vala/Bindings.
Doing it manually is no problem too. Suppose you have a library which defines SomelibClass1 in C with a method called do_something which takes a string.
The name of the headerfile is "somelib.h". Then the corresponding vapi is as simple as the following:
somelib.vapi:
[CCode (cheader_filename="somelib.h")]
namespace Somelib {
public class Class1 {
public void do_something (string str);
}
}
Documentation for writing vapis for non-GLib libraries can be found here: Vala/LegacyBindings
This is actually really easy. Lets take an excerpt from posix.vapi:
[Compact]
[CCode (cname = "FILE", free_function = "fclose", cheader_filename = "stdio.h")]
public class FILE {
[CCode (cname = "fopen")]
public static FILE? open (string path, string mode);
[CCode (cname = "fgets", instance_pos = -1)]
public unowned string? gets (char[] s);
}
This implements the following C-Function:
FILE *fopen (const char *path, const char *mode);
char *fgets (char *s, int size, FILE *stream);
When discarding the instance_pos attribute vala assumes that the object is the first parameter to a method. This way it is possible to bind c-constructs that are roughly object-oriented. The free_method of the compact-class is called when the object is dereferenced.
The CCode(cname)-attribute of a method, class, struct, etc. has to be the name of it as it would be in C.
There is a lot more to this subject, but this should give you a general overview.
It would probably be easier to just access your vala code from c. As all you have to do is just compile to C.