pkg-config --cflags libnfs returns an error with
this line:
$ pkg-config --cflags libnfs
Package @LIBNFS_PC_REQ_PRIVATE@ was not found in the pkg-config search path.
Perhaps you should add the directory containing `@LIBNFS_PC_REQ_PRIVATE@.pc'
to the PKG_CONFIG_PATH environment variable
Package '@LIBNFS_PC_REQ_PRIVATE@', required by 'libnfs', not found
Signed-off-by: Peter Lieven <pl@kamp.de>
This makes it possible for multiple processes/contexts to use the same
target and (with some synchronization) avoid XID collissions across processes/contexts.
This helps for users which rapidly fork a lot of processes that then
immediately create a new context (I am looking at you dbench)
to awoid having lots of processes starting and using overlapping xid values.
We use our own XDR and RPC layer nowadays and do not have
any external dependencies to XDR or RPC.
As such we no longer need to clamp the write size to max 32kb
since we never link to the system rpc/xdr libraries.
(and thus dont have to clamp in case the system library is broken for
pdu's > 32k)
Signed-off-by: Ronnie Sahlberg <ronniesahlberg@gmail.com>
- Allow nested eventloops so that a sync function can be called from a callback.
- Fix a bug in unmarshalling a uint64.
- Add PATHCONF support.
- WIN32/64 updates
- AROS updates
Add AROS/Amiga support
Chose initial XID value better to reduce probability for collissions
Fix bug in the initial default credentials and use getgid() instead of -1
use getgid() as the group instead of -1.
Recent linux knfsd do not allow grp==-1
On windows there are no uid/gids in the traditional sense so there I still specify a default credential of uid==gid==-1 :
rpc->auth = authunix_create("LibNFS", 65535, 65535, 0, NULL);
This is I think the sanest/safest thing to do since most servers will have
special handing of -1 meaning 'nobody' or similar.
This should work on many/most servers and give the user the minimum available
access allowed for 'nobody'.
I think on windows (or AROS for that matter) applications will probably have
to invoke and set the credentials themself explicitely.
Those apps probably, unfortunately, also need to have a configuration
setting to select which uid/gid to use when talking to the server.
(or they could hardcode it)
rpc_set_auth(rpc, libnfs_authunix_create("hostname", uid, gid, 0, NULL))
should do the trick if they call immediately after creating the rpc/nfs context.
But dont set it to 0,0 root/root for uid/gid.
First of all, most servers have root-squash so they will re-map this uid/gid
to 'nobody' internally.
But, if the user uses a server that does not do root-squash, then setting this to 0,0 would mean that your app now access the nfs share as root which is probably not what you want.
want to create an object straight under the root directory of what we
mounted.
As always, the actual object to create is then a string starting after the \0 byte
Peter Lieven