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

Benjamin C. Pierce bcpierce at cis.upenn.edu
Sat Sep 26 23:32:49 EDT 2015


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



More information about the Unison-hackers mailing list