On Tue, 19 Aug 2014, Joey Hess wrote: > Yaroslav Halchenko wrote: > > Original motivation was expressed here: > > https://github.com/data-git/datagit/issues/1
> > Through-away limited-view (i.e. some keys not present) could be useful > > e.g. to test for correct operation of a given data analysis pipeline > > given a subset of files (which were 'get'ed) > I think that if it's safe to hard-link in this situation, it could do it > by default without a new option. Unless it requires expensive checks.. thank you for considering this use-case. a 1c from paranoid me would be to not make it a default but a conscious user decision even though 'unlock/edit' copies the file out of the key store (which is what I thought could be the most dangerous flow which would just rename the file away from the keystore and adjust permissions for editing) > So, is it safe to hard-link in this situation? The complicating factors > I can think of are: > * Anything that changes the original file content would change the hard link > too. But these are annexed objects; nothing should be changing their > content. > * Hardlinked files share owner. So if the source and destination > repositories are being used by different users, hard linking would not > be a good idea. > * Hardlinked files also share permissions. So if core.shareRepository > has different settings between the source and destination repositories, > the files in them are supposed to have different modes and hard linking > cannot be used. > * This could weaken numcopies enforcement. If the goal is to ensure 2 copies > of a given file, then having both copies really be a single hard-linked > file would result in a lower than desired redundancy. yeap -- sounds like a good analysis/concerns, hinting once again to make it optional thus maintaining original "integrity" and solely allowing linked storage as user's choice -- for the throw-away clones (per my use case) above concerns unlikely be relevant. > Of course, git-annex already uses cp --reflink=auto in this case, so > if used on a filesystem that supports CoW, it'll already be as fast as a > hard link would be while avoiding all of the above complications (except > the numcopies one I suppose). if I got it right -- it is only btrfs which supports this, so pretty much only on a small portion of commodity installations could be used. -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
