Opened at 2017-06-22T05:37:43Z
Closed at 2018-01-05T00:11:57Z
#2880 closed defect (fixed)
Magic-folder needlessly creates ".backup" files after restart
Reported by: | cypher | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | undecided |
Component: | unknown | Version: | 1.12.1 |
Keywords: | magic-folder | Cc: | |
Launchpad Bug: |
Description
After placing a single file into a local magic-folder directory, a subsequent restart of the tahoe client will a create ".backup" copy of that file that is bit-for-bit identical to the original despite the fact that no changes have been made to the file on the "grid"-side to warrant it. As a demonstration:
dev ~ % cp cat.jpg Magic-Folder dev ~ % ls -al Magic-Folder total 116K drwxr-xr-x 2 user user 4.0K Jun 21 14:48 . drwxr-xr-x 57 user user 4.0K Jun 21 14:28 .. -rw-r--r-- 1 user user 107K Jun 21 14:48 cat.jpg dev ~ % tahoe restart STOPPING '/home/user/.tahoe' process 2592 is dead STARTING '/home/user/.tahoe' starting node in '/home/user/.tahoe' dev ~ % ls -al Magic-Folder total 224K drwxr-xr-x 2 user user 4.0K Jun 21 14:49 . drwxr-xr-x 57 user user 4.0K Jun 21 14:28 .. -rwx------ 1 user user 107K Jun 21 14:48 cat.jpg -rw-r--r-- 1 user user 107K Jun 21 14:48 cat.jpg.backup dev ~ % sha256sum Magic-Folder/cat.jpg* 7be4d6e0365150ef684545e29de088ed9419398f473d43c3c983afce6e9fdc72 Magic-Folder/cat.jpg 7be4d6e0365150ef684545e29de088ed9419398f473d43c3c983afce6e9fdc72 Magic-Folder/cat.jpg.backup
As far as I can tell, this occurs consistently with every run, thereby leading to the situation when, under ordinary usage, a user will eventually have a ".backup" duplicate for every file within their local magic-folder. This is undesirable not only due to the wasted disk space, but because the multititude of backup copies can impede the user's ability to distinguish a meaningful backup copy (i.e., one produced as a result of another's magic-folder member's action) from all the others.
Ideally, these files should only be generated under meaningful circumstances or when otherwise beneficial to the user (for example, when another magic-folder member overwrites or deletes the local user's copy).
Change History (4)
comment:1 Changed at 2017-09-19T19:34:30Z by cypher
- Priority changed from normal to major
comment:2 Changed at 2017-09-27T17:18:55Z by meejah
comment:3 Changed at 2017-10-26T19:10:12Z by meejah
https://github.com/tahoe-lafs/tahoe-lafs/pull/448 should be ready to go
comment:4 Changed at 2018-01-05T00:11:57Z by meejah
- Resolution set to fixed
- Status changed from new to closed
https://github.com/tahoe-lafs/tahoe-lafs/pull/448 was merged, fixing this bug
So what's happening is that when we upload a file, we don't set last_downloaded_uri in the local metadata. So then when we do a re-scan (at the next startup) we decide to download based on this missing URI. Every time a file is downloaded (and already exists locally) we make a .backup
The right fix is to set last_downloaded_uri upon upload, I believe -- thus we won't re-download the file on the next startup.
(Note this only happens *once* per new file we upload, not every startup).