+++ This bug was initially created as a clone of Bug #1487504 +++

Description of problem:
it is possible to append a file in immutable and undeletable state on a file-based worm volume

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

How reproducible:
[vagrant@client1 share]$ date && echo "testfile" >> testfile
Wed Aug 30 09:03:51 CEST 2017
[vagrant@client1 share]$ date && rm testfile
Wed Aug 30 09:04:07 CEST 2017
rm: cannot remove ‘testfile’: Read-only file system
[vagrant@client1 share]$ date && echo "testfile" >> testfile
Wed Aug 30 09:04:12 CEST 2017
[vagrant@client1 share]$ date && echo "testfile" >> testfile
Wed Aug 30 09:05:17 CEST 2017
[vagrant@client1 share]$ date && rm testfile
Wed Aug 30 09:05:21 CEST 2017
[vagrant@client1 share]$



Steps to Reproduce:
1.create volume. enable file-based worm
2.features.worm-file-level: on
features.default-retention-period: 60
features.auto-commit-period: 5
3.follows steps in "how reproducible"

Actual results:
the file was appended

Expected results:
it should not be possible to append files in immutable undeletable state 


Additional info:

--- Additional comment from Jurgen Reij on 2017-09-01 02:27 EDT ---



--- Additional comment from Jurgen Reij on 2017-09-01 02:27 EDT ---



--- Additional comment from Karthik U S on 2017-09-06 03:16:15 EDT ---

It is not appending any content to the worm-retained file. The problem here is when we do an append write we do not print the EROFS error. If you check the actual contents of the file after the append write it won't be changed.
Try appending some new contents instead of doing
echo "testfile" >> testfile
which is same as the original content of the file. If you see the brick logs it will show the EROFS error message for the append writes.

If you can see the new contents appended to the worm-retained/worm file, please let me know.

--- Additional comment from Jurgen Reij on 2017-09-28 05:40:46 EDT ---

Karthik,

See my results:

[vagrant@client1 share]$ date && echo "test1" >> testfile
Thu Sep 28 11:38:57 CEST 2017
[vagrant@client1 share]$ date && echo "test2" >> testfile
Thu Sep 28 11:39:10 CEST 2017
[vagrant@client1 share]$ cat testfile
test1
test2

--- Additional comment from Karthik U S on 2017-09-28 06:20:37 EDT ---

Hi Jurgen Reij,

Current code does not have the state transition mechanism in the write code path. This is a bug and we have a dependency on some other thing for this. Once that is fixed we will do transition in the write path as well, so the next writes will be blocked.
Let me try to explain the scenario in your test. First you created the testfile. After 13 seconds you are trying to do append write, and expect it to be blocked since the auto-commit-period is 10secs. Since it is an append write, and not link, unlink, rename, or truncate (the only 4 fops which does the state transition in the current code), it won't check for the state transition  and does the next write. So the content gets updated.
Instead of checking only the date, check the stat of the file. The atime will point to a future value after state transition to worm-retained state which will then be equal to the "time at which transition happened + the retention period". In normal state it will allow append write.

We will fix the behaviour so write fops will also do the state transition.

--- Additional comment from Worker Ant on 2017-10-24 05:15:24 EDT ---

REVIEW: https://review.gluster.org/18560 (write once read many: file appendable in worm state) posted (#1) for review on master by Vishal Pandey (vpandey)

--- Additional comment from Worker Ant on 2017-10-24 05:40:20 EDT ---

REVIEW: https://review.gluster.org/18560 (write once read many: file appendable in worm state) posted (#2) for review on master by Vishal Pandey (vpandey)