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

[Benjamin C. Pierce]

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

IIRC, backups are done with “mv”, so the mtime of the original file will be preserved.  I’m not sure what’s the best way to implement this kind of tidying script.

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

This is what I do.  (Not every time, but periodically when I notice my disk filling up.)

    - B


> 
> 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
> _______________________________________________
> Unison-hackers mailing list
> Unison-hackers at lists.seas.upenn.edu
> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers