[Unison-hackers] [FeatureReqest] auto-delete unneeded backup-files

[Frederik Eaton]

Since Benjamin asked for other opinions, I'll agree that removing
backups of deleted files sounds like a bad idea, but I think there's
an issue regarding how to manage backups in general. My preference
would be to avoid having this complexity in Unison, but to make it
easy for users to delete backups made more than X days ago using a
special 'find' command with an example in the manual. Experimenting
with my own 'backup' directory, it looks like the 'mtime' of backups
reflects when the backup was made, is this correct? In which case one
could do

find .unison/backup/ -mtime +20 | xargs rm

to remove backup files created more than 20 days ago. However, running
just 'find' I now see that there seem to be some files in this
directory whose 'mtime' predates the time when I started saving
backups, so maybe 'mtime' isn't the right metric, or perhaps the
Unison code needs to be modified so that 'mtime' works for this
purpose.

Of course, I mostly use Unison backups to recover from typing the
wrong thing at the Unison prompt, so I could just delete the entire
backup directory as soon as I'm confident that I ran Unison correctly.

Frederick

On Sat, Sep 26, 2015 at 11:32:49PM -0400, Benjamin C. Pierce wrote:
> I’d be interested to hear opinions from others on the list.  Personally, I think I probably would not want Unison ever to remove backups of deleted files (though, somewhat inconsistently, I do use the maxbackups feature).  But if there are many others that would find this feature useful, I would not object strongly to its being added, as long as it is easy to control and off by default.
> 
>     - Benjamin
> 
> > On Sep 26, 2015, at 4:27 PM, c.buhtz at posteo.jp wrote:
> > 
> > This FR is related to this Thread on the user-List
> > <https://groups.yahoo.com/neo/groups/unison-users/conversations/topics/11660>
> > 
> > I am asking for such a feature because I want to have the opinion of
> > the maintainers of that project.
> > I am aware of the current status (not in active developend) and of the
> > less resources of the project.
> > I don't ask about if you (the maintainers) have the resources to
> > implement that. I am just asking if you think it is a good idea and you
> > would accept a patch/pull-request. Maybe you hate this idea and would
> > never accept that feature in an official unison release. It is
> > important do know for any developer who try to implement that.
> > 
> > The Feature:
> > Unison should check if the backup-files have a corrosponding original
> > file. If the original file doesn't exists anymore something should be
> > done (e.g. delete it). This could be depended on the age of the
> > bak-file, on the size of the complete backup-directorie, etc.
> > This would prevend the user for wasting storage space. When the user
> > delete an original file the backup-file is still there. Most of the use
> > cases it is in a hidden directory. So the user never think about that.
> > Using unison for some years this would produce a lot of files.
> > 
> > In my opinion and habit of developing software this FR could be a
> > bug-report, too.
> > The use of bak-files is not fully implemented. Unison create them
> > automaticly but doesn't take care of there deletion. In german we say:
> > "When you say A you have to say B, too."
> > 
> > Minimaly there should be a big-red-bold-hint in the manual about the
> > possible excessive use of storage space the user should take care about
> > himself.
> > 
> > So what is your opinion about this feature and would you accept it no
> > matter about your own resources?
> > -- 
> > -----BEGIN PGP PUBLIC KEY BLOCK-----
> > Version: GnuPG v1
> > 
> > mQENBFQIluABCACfPwAhRAwFD3NXgv5CtVUGSiqdfJGVViVBqaKd+14E0pASA0MU
> > G0Ewj7O7cGy/ZIoiZ0+lIEZmzJKHfuGwYhXjR/PhnUDrQIHLBvh9WuD6JQuULXfH
> > kXtVm/i9wm76QAcvr2pwYgNzhcJntUHl2GcgnInYbZDeVmg+p9yIPJjuq73/lRS3
> > 0/McgNoFOBhKK/S6STQuFyjr9OyJyYd1shoM3hmy+kg0HYm6OgQBJNg92WV9jwGe
> > GzlipvEp2jpLwVsTxYir2oOPhfd9D1fC9F/l/3gXbfjd5GIIVrZFq2haZmoVeJ33
> > LJxo3RA5Tf9LoUeels1b4s9kFz6h7+AHERUpABEBAAG0IUNocmlzdGlhbiBCdWh0
> > eiA8YnVodHpAcG9zdGVvLmRlPokBPgQTAQIAKAUCVAiW4AIbAwUJAeEzgAYLCQgH
> > AwIGFQgCCQoLBBYCAwECHgECF4AACgkQZLsXsAdRqOxNUAf/V/hDA5zGDpySuCEj
> > DhjiVRK74J9Wd8gfH0WAf1Co5HZ24wZH8rgOIVIgXw8rWkOw/VA6xfdfT+64xjTY
> > Fhkpbrk199nDzp72F7Jc4NC+x8xac2e3rK5ifSWhZx7L5A32pGYE+d16m3EEqImK
> > D4gcZl38x9zdUnD4hHyXkIPz1uCfuMuGgWEnaUk4Wbj41CBZr3O0ABue6regV15U
> > jaes8r+B8iCcY+0yP2kse+3iaCaMqNv5FgQZ9+b2Cql8pFkZJVtBVUw4GW3DWZJi
> > du0O/YrC9TgS+xY9ht/MD2qSHwjcK1sdImjqBO7xP8TIOwKeYyDvGKnSO3EJ/sSA
> > UPGEPrkBDQRUCJbgAQgA0k/Qg67CCUJE2/zuxBEoK4wLJpDRJzh8CQPZpjWx8VP0
> > KL892jwfxymXn8KNhuy1SgCBFSeV9jg4VZNWDlUGJc2lo82ajr9PzIsrQwu4lf0B
> > zrUWV5hWepKu/kb8uSjx58YYfx0SFz4+9akX3Wwu9TUHntzL5Gk3Q26nnsr1xEJ+
> > VEumvCH9AE0Tk0K7dQpJ2/JcLuO+uhrpd/lHFDYVN5NsG3P015uFOkDI6N/xNFCj
> > v95XNR93QlfKpK3qWlFGescfG+o/7Ub6s67/i/JoNbw0XgPEHmQfXpD7IHO4cu+p
> > +ETb11cz+1mmi96cy98ID+uTiToJ8G//yD9rmtyxoQARAQABiQElBBgBAgAPBQJU
> > CJbgAhsMBQkB4TOAAAoJEGS7F7AHUajs6sQH/iKs6sPc0vkRJLfbwrijZeecwCWF
> > blo/jzIQ8jPykAj9SLjV20Xwqg3XcJyko8ZU6/zuRJq9xjlv9pZr/oVudQAt6v+h
> > 2Cf4rKEjmau483wjMV2xjTXQhZi9+ttDbia4fgdmGtKsOicn5ae2fFXcXNPu3RiW
> > sZKifWdokA6xqMW6iIG9YjjI5ShxngHWp2xfPscBFMDRtFOMags/Yx+YvwoyEZ4A
> > dURYMFHFqpwILEc8hIzhRg1gq40AHbOaEdczS1Rr3T7/gS6eBs4u6HuY5g2Bierm
> > lLjpspFPjMXwJAa/XLOBjMF2vsHPrZNcouNKkumQ36yq/Pm6DFXAseQDxOk=
> > =PGP9
> > -----END PGP PUBLIC KEY BLOCK-----
> > _______________________________________________
> > Unison-hackers mailing list
> > Unison-hackers at lists.seas.upenn.edu
> > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers
> 
> _______________________________________________
> Unison-hackers mailing list
> Unison-hackers at lists.seas.upenn.edu
> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers