Bug 1461808

Summary:	glfs_get_volumeid() returns junk strings
Product:	[Red Hat Storage] Red Hat Gluster Storage	Reporter:	Prasanna Kumar Kalever <prasanna.kalever>
Component:	libgfapi	Assignee:	Poornima G <pgurusid>
Status:	CLOSED NOTABUG	QA Contact:	surabhi <sbhaloth>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rhgs-3.3	CC:	amukherj, ndevos, prasanna.kalever, rhinduja, rhs-bugs, storage-qa-internal
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-06-20 09:26:12 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Comment 3 Poornima G 2017-06-16 09:49:32 UTC

My apologies, missed in the first code walktrough. So, the glfs_get_volumeid gives the UUID in uuid_t format i.e. as opaque data of 16 bytes and is non printable. Hence, the printf on uuid is wrong usage. The API documentation in glfs.h clearly states that the uuid returned is opaque.

Hence this is not a bug. Please confirm the same.

Also for your use case, you can store the uuid as opaque and compare the uuids using memcmp()

Comment 4 Niels de Vos 2017-06-19 08:45:12 UTC

I stronly recommend to not use an opaque value if you care about calling glfs_get_volumeid(). Store it in a uuid_t, and don't use memcmp() to compare but use uuid_compare() instead :)

We can not change glfs_get_volumeid() because there are other users of this function (at least NFS-Ganesha).

This should probably be closed as NOTABUG, please do so while replying with your acceptance.

Comment 7 Niels de Vos 2017-06-19 11:43:42 UTC

Also, Prasanna, what is your use-case for calling glfs_get_volumeid() in the first place? Normal users should really not need to know the volume-id...

Comment 10 Poornima G 2017-06-20 09:15:42 UTC

So hence we can close this bug and work as a part of some other bug https://bugzilla.redhat.com/show_bug.cgi?id=1459850 may be?