+++ This bug was initially created as a clone of Bug #1214561 +++ Description of problem: Glusterfind API presently is just able to mention the files which have been newly created, or have had data/metadata changes. In case a file is deleted, it is not able to get that information from the changelog file This bug is to track the progress made on that front. Version-Release number of selected component (if applicable): Glusterfs 3.7 upstream How reproducible: Always Steps to Reproduce: 1. Have a gluster volume of type distribute/replicate 2. Create 2 files 'file1' and 'file2' 3. Edit the contents of 'file2' 4. Delete 'file2' 5. Change the permissions of 'file1' to (say) read-only 6. Verify the contents of changelog file. Actual results: Step 6 should shows Entry operations for 'file1' and 'file2', followed with Data operation for 'file2', and a Metadata operation for 'file1' Delete operation of 'file2' (step4) is not recorded in the changelog file. Expected results: Delete operation of 'file2' should get recorded in the changelog file, which in turn can be used by Glusterfind.
Patch sent: http://review.gluster.org/#/c/10535/
COMMIT: http://review.gluster.org/10535 committed in release-3.7 by Vijay Bellur (vbellur) ------ commit edfe56dfd8ceb4ef0c160484de04af30e8f5b7df Author: Kotresh HR <khiremat> Date: Tue Apr 14 14:42:46 2015 +0530 feature/changelog: Capture path for deletes PROBLEM: There is no way to get the path of deleted file if we have gfid from changelog since the file is already deleted. SOLUTION: Do a recursive readlink on parent gfid in backend .glusterfs path to get the complete path in I/O callpath in changelog translator and capture it in callback. The path captured is relative from the brick root. The field separator used is '\0'. e.g., ......\0<pgfid>/bname\0<relative-path>\0<next-record> ADDITIONAL REQUIRED CHANGES: 1. The changelog translator option called "changelog.capture-del-path" is introduced to enable or disable the capturing of deleted entry path. e.g., gluster vol set <vol-name> changelog.capture-del-path on/off If capture-del-path is disabled, '\0' is captured instead of relative path. e.g., ......\0<pgfid>/bname\0\0\0<next-record> 2. The minor number in the version of changelog is bumped up from v1.1 to v1.2. 3. If recursive readlink is failed for some reason, it will capture \0 in place of <relative path>. e.g., ......\0<pgfid>/bname\0\0\0<next-record> (same as when caputre-del-path option is disabled) 4. If bname argument passed to "resolve_pargfid_to_path" function is NULL and pargfid is ROOT, "." is returned. This is not the case with changelog, where bname is always passed. This is applicable to other consumers of "resolve_pargfid_to_path" routine. NOTE: Changelog parser should consider the above new changes and should parse accordingly. BUG: 1218383 Change-Id: I5d89cf4157befd207771f6c0248d2493fbf85832 Signed-off-by: Kotresh HR <khiremat> Reviewed-on: http://review.gluster.org/10288 Reviewed-on: http://review.gluster.org/10535 Tested-by: Gluster Build System <jenkins.com> Tested-by: NetBSD Build System Reviewed-by: Aravinda VK <avishwan> Reviewed-by: Vijay Bellur <vbellur>
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.7.0, please open a new bug report. glusterfs-3.7.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution. [1] http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/10939 [2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user