We are trying to create a version history so that we can serialize all versions in CTO fashion. But when using vim, it moves the original file (with the original version number) to a new file, then creates a new file (and therefore a new version history) with the new data.
I am trying to bump the version number, but the following is happening when I'm using vim:
Open new file foo.txt, write a line, save and close the file.
File is flushed, assigned version (1,1), iNode 1
Open file append a line, save and close the file.
iNode 1 with version (1,1) is moved to foo.txt~
iNode 2 is created as foo.txt (but no version history)
File is flushed, assigned version (1,1), iNode 2
iNode 1 (foo.txt~) is removed
Note that there are .swp, .swx, .swo files in there as well.
So basically our versioning system expects the namespace to not change out from under it, like it is in this case. Other bash programs do this too (mv orig to a backup and write a new version), and we wouldn't get linearizability as a result.
Also foo.txt~ is not flushed, so there no record of it in the db and it wouldn't be sent to Raft (which is why it's taken me forever to find this bug).
We are trying to create a version history so that we can serialize all versions in CTO fashion. But when using vim, it moves the original file (with the original version number) to a new file, then creates a new file (and therefore a new version history) with the new data.
I am trying to bump the version number, but the following is happening when I'm using vim:
Note that there are .swp, .swx, .swo files in there as well.
So basically our versioning system expects the namespace to not change out from under it, like it is in this case. Other bash programs do this too (mv orig to a backup and write a new version), and we wouldn't get linearizability as a result.
Also foo.txt~ is not flushed, so there no record of it in the db and it wouldn't be sent to Raft (which is why it's taken me forever to find this bug).