Magic Folder: how do we know whether deletion is intentional?

[daira]

For Magic Folder to be useful for backup, files should be retained if they are accidentally deleted. But if deletion is intentional, they should be deleted from all replicas. I had been thinking that if files were deleted when the gateway was not running, then they should be restored on startup; however this makes the behaviour when running and non-running inconsistent.

[zooko]

We should call this functionality something like "expunging" or something, and IMHO we should put off any implementation of it to some future stage. For now I think it should be impossible to remove files from Magic Folders history.

[daira]

Zooko: the current Magic Folder design doesn't retain old versions of files. (It would be a relatively straightforward change to make it do so, but it's not clear what the UI would be, and we decided that supporting this was out of scope for the OTF grant.)

[daira]

I propose that the Magic Folder implementation not do anything special to handle deleted files on startup. That is, a file that is found to have been deleted while the node was not running is treated in the same way as a file that is deleted just after it has started.

(Currently, that is to upload a deletion marker, which will cause other nodes to rename their copy of the file to $FILENAME.backup if they have it, or do nothing if they do not already have it.)

[lpirl]

Replying to daira:

(Currently, that is to upload a deletion marker, which will cause other nodes to rename their copy of the file to $FILENAME.backup if they have it, or do nothing if they do not already have it.)

Actual deletion does not happen anyways, does it? Could backup files also be named $FILENAME.backup_<timestamp>? But his accumulates a lot of old files over time… for users that do not want this, it could be optional.

[daira]

Replying to lpirl:

Replying to daira:

(Currently, that is to upload a deletion marker, which will cause other nodes to rename their copy of the file to $FILENAME.backup if they have it, or do nothing if they do not already have it.)

Actual deletion does not happen anyways, does it?

No. But there may be no other copy of the file in some cases (if it was deleted from the client on which it was created, before it was uploaded and then downloaded by any other client).

Could backup files also be named $FILENAME.backup_<timestamp>? But his accumulates a lot of old files over time… for users that do not want this, it could be optional.

Yes, that was anticipated but not required for the OTF grant proposal.

[dawuud]

i think this ticket can be closed. we are already working on better conflict detection here: ​https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2582

and in at least one of our new proposed data models ambient deletion authority is removed by logging all historical versions of a file.

[daira]

We should only close this when/if we have decided that the model we're going to implement will address this problem.

[exarkun]

magic-folder has been split out into a separate project - ​https://github.com/leastauthority/magic-folder