summaryrefslogtreecommitdiffstats
path: root/api/src/glfs-resolve.c
Commit message (Collapse)AuthorAgeFilesLines
...
* gfapi: handle root (/) resolution gracefully for realpath()Anand Avati2013-04-231-1/+4
| | | | | | | | | | | Resolving path of / is crucial for realpath() to work properly. Change-Id: I8a1b482beba37f01afbd20446d9e6f6125f2ec34 BUG: 953694 Signed-off-by: Anand Avati <avati@redhat.com> Reviewed-on: http://review.gluster.org/4872 Tested-by: Gluster Build System <jenkins@build.gluster.com> Reviewed-by: Vijay Bellur <vbellur@redhat.com>
* gfapi: support for chdir() and familyAnand Avati2013-04-191-4/+26
| | | | | | | | | | | | Add support for chdir, fchdir, getcwd, realpath equivalents in GFAPI. These are required for the Samba VFS plugin. Change-Id: I91d2db9146994403c98961c489c7640c51d5add2 BUG: 953694 Signed-off-by: Anand Avati <avati@redhat.com> Reviewed-on: http://review.gluster.org/4853 Tested-by: Gluster Build System <jenkins@build.gluster.com> Reviewed-by: Vijay Bellur <vbellur@redhat.com>
* gfapi: dict_unref() xattr_req in fop finish instead of dict_destroy()Anand Avati2013-03-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | The current way of calling dict_destroy() at the end of an API fop assumes that xattr_req is not stored/ref'd by any translators in the stack. However when translators like DHT store xattr_req in dht_local_t with a dict_ref() and perform dict_unref() in the unwind path, things get subject to a race. The race is between the woken up thread (by syncop_wake) i.e, the gfapi invoking thread and the thread where the FOP was unwound. As the C stack of STACK_UNWIND unwinds back, dht_local_unref() gets invoked within the DHT_STACK_UNWIND macro. This thread attempts dict_unref, which would be "safe" if it wins the race against the gfapi invoking thread. However if the gfapi invoking thread wins the race, it will perform dict_destroy() first and therefore make dict_unref() within dht_local_unref perform a double free. This is the embarrassing on-screen bug which showed up in a roomful of people during the gluster dev summit demo of qemu/libgfapi integration. Change-Id: I284c93de87cdc128d5801f42c84aa87f753090d4 BUG: 839950 Signed-off-by: Anand Avati <avati@redhat.com> Reviewed-on: http://review.gluster.org/4644 Reviewed-by: Jeff Darcy <jdarcy@redhat.com> Tested-by: Gluster Build System <jenkins@build.gluster.com>
* glfs-resolve: fix resolution of "/"Anand Avati2012-10-031-2/+27
| | | | | | | | | Change-Id: I78d63b39dde14a9a32ea197cf0dedeb5695b35c9 BUG: 839950 Signed-off-by: Anand Avati <avati@redhat.com> Reviewed-on: http://review.gluster.org/4021 Tested-by: Gluster Build System <jenkins@build.gluster.com> Reviewed-by: Amar Tumballi <amarts@redhat.com>
* gfapi: fix the failure in glfs_open()Amar Tumballi2012-09-251-1/+1
| | | | | | | | | | | | | * the issue is happening because the resolve_symlink() logic was reversed Change-Id: I10eca14d82e3ebf5a0195d5db1330f9e1a3e2dc4 Signed-off-by: Amar Tumballi <amarts@redhat.com> BUG: 839950 Reviewed-on: http://review.gluster.org/3978 Tested-by: Gluster Build System <jenkins@build.gluster.com> Reviewed-by: Jeff Darcy <jdarcy@redhat.com> Reviewed-by: Anand Avati <avati@redhat.com>
* gfapi: add symlink (auto resolution) support in resolverAnand Avati2012-09-171-3/+93
| | | | | | | | | | | | - new internal API glfs_lresolve() for usage with APIs like glfs_lXXXX() (e.g. glfs_lstat()) Change-Id: I61c60af6bda3072f189684ad8ac9815d59f455fc BUG: 839950 Signed-off-by: Anand Avati <avati@redhat.com> Reviewed-on: http://review.gluster.org/3866 Tested-by: Gluster Build System <jenkins@build.gluster.com> Reviewed-by: Amar Tumballi <amarts@redhat.com>
* gfapi: API/library for accessing gluster volumesAnand Avati2012-07-181-0/+244
Change-Id: Ie4cbcf91b58218bebf23cf951c313aceeb29f311 BUG: 839950 Signed-off-by: Anand Avati <avati@redhat.com> Reviewed-on: http://review.gluster.com/3664 Tested-by: Gluster Build System <jenkins@build.gluster.com> Reviewed-by: Jeff Darcy <jdarcy@redhat.com> Reviewed-by: Kaleb KEITHLEY <kkeithle@redhat.com> Reviewed-by: Bharata B Rao <bharata.rao@gmail.com>