Bug 1284371 - [WORM] Rename operation succeeds on a WORM enabled volume after one brick is added
Summary: [WORM] Rename operation succeeds on a WORM enabled volume after one brick is ...
Keywords:
Status: CLOSED EOL
Alias: None
Product: GlusterFS
Classification: Community
Component: core
Version: 3.7.6
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Atin Mukherjee
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-11-23 07:50 UTC by Fang Huang
Modified: 2017-03-08 11:03 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 1283509
Environment:
Last Closed: 2017-03-08 11:03:38 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Embargoed:


Attachments (Terms of Use)

Description Fang Huang 2015-11-23 07:50:47 UTC
+++ This bug was initially created as a clone of Bug #1283509 +++

Description of problem:

If we expand a new brick to a WORM volume and create some new files, the files located in the new brick can be renamed.

Version-Release number of selected component (if applicable):


How reproducible:

Always

Steps to Reproduce:
1. create a dht volume and enable WORM feature
2. add one brick to the volume
3. fix layout of the volume
4. create some files in the client directory
5. rename files which are located in the new added brick

Actual results:

Mv operation succeeds without any error reported. But the new name and the original name both exists.

Expected results:

Mv operation is not allowed.

Additional info:

Comment 1 Kaushal 2017-03-08 11:03:38 UTC
This bug is getting closed because GlusteFS-3.7 has reached its end-of-life.

Note: This bug is being closed using a script. No verification has been performed to check if it still exists on newer releases of GlusterFS.
If this bug still exists in newer GlusterFS releases, please reopen this bug against the newer release.


Note You need to log in before you can comment on or make changes to this bug.