#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

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).

Version 0, edited at 2017-09-27T17:18:55Z by meejah (next)

comment:4 Changed at 2018-01-05T00:11:57Z by meejah

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.