Description of problem: Since RHS 3.1, ".trashcan" directory is visible from FUSE mount to a client. As this is first level directory in the glusterfs volume, it also shows up as a container when a GET operation is performed on the account (the volume) over Swift. Version-Release number of selected component (if applicable): ------------------------------------------------------------- RHS 3.1 swiftonfile-1.13.1-2 How reproducible: ----------------- Perform a GET request on the account using curl. Breakage of object expiration functionality: -------------------------------------------- The special volume "gsexpiring" should contain directories whose names are timestamp - a number. The object expirer daemon code breaks because of following code being executed: int(".trashcan") This part of code cannot be modified as it's part of Swift RPMs. Actual results: .trashcan directory visible as a container. Also object expirer daemon raises exception. Expected results: .trashcan directory should not be visible as a container. Object expirer daemon should not raise an exception. Additional info:
Upstream fix: https://review.openstack.org/211869
Patch merged upstream.
Tested with swiftonfile-1.13.1-4.el7rhgs.noarch GET request on the container no longer gets .trashcan Marking this bug as verified
Prashanth, Please review and sign-off the edited doc text.
Doc text with some corrections: "Previously, .trashcan directory which is always present in the root of the volume was considered to be a container and was returned in container listing. With this fix, .trashcan directory is no longer returned in container listing."
Updated the doc text with minor edits.
Thanks Divya. Looks good to me.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2015-1845.html