New cache type: read-only hardlink

[dmpetrov]

It is often confusing that user can edit the data files and it breaks immutable cache. Often it is not clear for users. An example #754.

The data file read-only semantic should be clear. Let's:

1. Introduce a new CacheType - read-only hardlink ro-hardlink.
2. Make ro-hardlink as the default type for file systems without reflinks support.

btw... It should be easy to implement (2) without breaking the back compatibility - just keep hardlink as the default type and create a config file with ro-hardlink in new dvc versions.

We should understand that ro-hardlink will change the expected Git-like behavior (dvc will change data file permissions) but it will protect immutable cache which is more important.

[efiop]

I think a better way to achieve this would be to introduce 'protected' mode for dvc repository. I.e. dvc config core.protected true will tell dvc to set read-only permissions on data files(both hard and symlinks). Plus we would introduce dvc protect/abandon(similar to git annex lock/unlock, but our dvc lock\unlock are already taken by stage locking) that will allow to set and unset read-only permissions on individual files. dvc abandon file.dvc will replace links to read-only cache with copies that will have write-permissions thus keeping the cache safe.

[dmpetrov]

It looks like this feature should become a default behavior in dvc 1.0 (with the dvc commit). @efiop what do you think?

Protect\Abandon - does it affects all the cache types?

• Hardlink - yes
• Reflink - no
• Symlinks - yes?

[efiop]

@dmpetrov I agree, we should definitely consider making it a default behaviour for 1.0 . And yes, only hardlinks and symlinks should be protected by default.

[dmpetrov]

So, 2 cache types (Hardlink and Symlinks) need the new parameter (Protect\Abandon) for the cache immutability and other 2 types (Reflinks and Copy) do not need that.

As a result, DVC can protect immutable data files in two possible ways:

1. Introduce new cache types ro-hardlink and ro-symlink (and use them by default).
2. Introduce a global config parameter Protection = Protect|Abandon for hardlink and symlink instead.
   2.1. Add an ability to change hardlink and symlink protection settings per file - dvc protect\abandon file.dvc. To me, it is hard to imagine a realistic scenario for this feature, but I like the flexibility it provides. It is probably okay if we hide this feature from basic use cases.

@efiop could you please clarify if my understanding is correct?

[efiop]

Introduce new cache types ro-hardlink and ro-symlink (and use them by default).

Correct, the pros for this one is that it fits nicely in the currect cache.type logic. We will still have to introduce something similar to dvc protect|abandon to provide a convenient way to modify a file if it is protected.

Introduce a global config parameter Protection = Protect|Abandon for hardlink and symlink instead.
2.1. Add an ability to change hardlink and symlink protection settings per file - dvc protect\abandon file.dvc. To me, it is hard to imagine a realistic scenario for this feature, but I like the flexibility it provides. It is probably okay if we hide this feature from basic use cases.

I was actually thinking about something like core.protected = true|false, but it is essentially the same thing. I am also considering it affecting all cache types, just for the simple symmetry, but I'm not yet sure. Will reconsider all the options while preparing a PR for this. My current draft is using core.protected for all the cache types and also provides dvc protect + dvc abandon CLI commands. But I definitely need to give it a better thought.

[dmpetrov]

Good! It looks like the protected config param is a better solution. However, two additional commands dvc protect/abandon for a very rare use case (why I need to make a data file mutable?) look like an overkill.

We should think more about how to avoid these commands.