Description of problem: As mentioned in the summary, Gluster allows renaming of folders, which contain WORMed/Retain or WORMed files. The path of a file is part of the files identity and someone should not be allowed to change it, if the file is in WORMed/Retain or WORMed state. This behaviour does not match the definition of WORM which means that a file can not be changed after it was write initially Version-Release number of selected component (if applicable): 3.12.5 How reproducible: You need access to a gluster volume via FUSE or something else and worm-file-level must be switched on. Steps to Reproduce: $ mkdir test $ echo test >> test/test.txt $ chmod 444 test/test.txt $ mv test test1 Actual results: The command "mv test test1" can be done without error. Expected results: After executing the command "mv test test1" the system should not allow this command Additional info: none
Hi David, I know you sent couple of patches previously for WORM, and we did fix issues like delete etc. Is this still an issue in latest master?
Hello Amar, yes, it is still an issue. If a folder (or a subfolder of this folder) contains a WORMed file, it shouldn't be allowed to rename the folder
Had a discussion with Karthik and he is suspicious of why we need this change. Few reasons why this change might not be needed -
(In reply to Vishal Pandey from comment #3) > Had a discussion with Karthik and he is suspicious of why we need this > change. Few reasons why this change might not be needed - 1- Rename will not change the contents or metadata of the files inside src directory 2- Rename will not change the xattrs specific to WORM feature on the files 3- The dir can contain other files as well which may not be WORM-Retained or WORMed yet 4- Also even if we do check a directory if it has worm files or no, it will take a long time in case when the number of files are too large.
I have mentioned some of the reasons why this feature might not be needed afetr some discussions with Karthik. If there is anything else anyone would like to add or else can we close the issue ?
I followed the discussion and I agree to the arguments. You can close the issue from my point of view
Thanks for the ack David. Closing this bug as per comment #7.