: [gpfsug-discuss] GPFS API
On 17/12/2018 17:35, Simon Thompson wrote:
> Indeed.
>
> Actually this was exactly what we were trying to work out. We'd set
> the buf size to 0 hoping it would tell us how much we need, but we
> kept getting EINVAL back - which the docs states is invalid path,
On 17/12/2018 17:35, Simon Thompson wrote:
Indeed.
Actually this was exactly what we were trying to work out. We'd set
the buf size to 0 hoping it would tell us how much we need, but we
kept getting EINVAL back - which the docs states is invalid path, but
actually it can be invalid bufsize as
On 17/12/2018 17:35, Simon Thompson wrote:
Indeed.
Actually this was exactly what we were trying to work out. We'd set
the buf size to 0 hoping it would tell us how much we need, but we
kept getting EINVAL back - which the docs states is invalid path, but
actually it can be invalid bufsize as
rs!
Simon
From: gpfsug-discuss-boun...@spectrumscale.org
[gpfsug-discuss-boun...@spectrumscale.org] on behalf of Jonathan Buzzard
[jonathan.buzz...@strath.ac.uk]
Sent: 17 December 2018 16:46
To: gpfsug main discussion list
Subject: Re: [gpfsug-discuss] GPFS API
On Mon,
On Mon, 2018-12-17 at 10:47 -0500, Marc A Kaplan wrote:
> Look in gps.h I think the comment for acl_buffer_len is clear
> enough!
>
I guess everyone does not read header files by default looking for
comments on the structure ;-)
One thing to watch out for is to check the return from
acl_var_data[1]; /* OUTPUT: Remainder of the ACL
information. */
} gpfs_opaque_acl_t;
From: Simon Thompson
To: "gpfsug-discuss@spectrumscale.org"
Date: 12/17/2018 10:13 AM
Subject: [gpfsug-discuss] GPFS API
Sent by:gpfsug-discuss-boun...@spectrumscale.o
Hi,
This is all probably perfectly clear to someone with the GPFS source code but …
we’re looking at writing some code using the API documented at:
https://www.ibm.com/support/knowledgecenter/STXKQY_5.0.1/com.ibm.spectrum.scale.v5r01.doc/pdf/scale_cpr.pdf
Specifically gpfs_getacl() function,
/2016 06:37 PM
Subject: Re: [gpfsug-discuss] GPFS API O_NOFOLLOW support
Sent by:gpfsug-discuss-boun...@spectrumscale.org
Thanks Yuri! I do wonder what security implications this might have for
the policy engine
m: Aaron Knister <aaron.s.knis...@nasa.gov>
To: <gpfsug-discuss@spectrumscale.org>
Date: 07/22/2016 06:37 PM
Subject: Re: [gpfsug-discuss] GPFS API O_NOFOLLOW support
Sent by:gpfsug-discuss-boun...@spectrumscale.org
Thanks Yuri! I do wonder what security implic
Hi Everyone,
I've noticed that many GPFS commands (mm*acl,mm*attr) and API calls (in
particular the putacl and getacl functions) have no support for not following
symlinks. Is there some hidden support for gpfs_putacl that will cause it to
not deteference symbolic links? Something like the
10 matches
Mail list logo
