[darcs-devel] [issue1645] Darcs >2.3 follows directory symlinks.

[Eric Kow]

Hi Reinier,

Just pointing out that this ticket may require blocking the 2.4.1
release until Petr gets back (middle of next week) and we have time to
review hashed-storage 0.4.11 (by weekend?).  Hmm, then again maybe
that's too rushed and we'd be better off waiting for a 2.4.2 to play it
safe?  We could try to fix it ourselves urgently but that sounds like it
could be riskier :-)

Hi Dmitry,

Great reply!  This sort of thing is helpful to me because I often go
through the bug tracker in stupid-mode (throughput-maximisation over
quality) and miss things people have already said.  :-(
So having things put all in order is useful for me.

[Re-arranging some of your comments to fit my reply]

On Thu, Apr 01, 2010 at 14:05:14 +0100, Dmitry Astapov wrote:
> > 1. Is this really a problem? Question to Dmitry and Trent: why is the
> > boring file mechanism not good enough of a workaround?

> Boring file mechanism does not solve this because it does not cover
> all possible use cases.  Repository could contain symlinks to
> non-bored files and/or directories.

I meant putting the source path (eg. loop and loop2) in boring.
Would that cover those use cases?

> This basically means that I have to go and add each and every symlink to
> "boring" in order to be able to do anything useful with darcs-2.4.

Ah, so I think this answers the question I meant to ask.

Would something like

   find . -type l >> _darcs/prefs/boring

do the trick or are there shortcomings I have still failed to
anticipate?

> 1)it follows symlinks eagerly and could fall into endless loop

> mkdir repo
> cd repo
> darcs init
> ln -s . loop

...

> 2)symlinks to non-boring directories (even non-recursive ones) throw darcs
> off the rails.

> rm loop
> mkdir d1
> darcs add d1
> darcs rec d1
> cd d1
> ln -s ../d1 loop2
> cd ..

These sound like really good test cases.

Could you modify our tests/failing-issue1645... accordingly and darcs
send the results?  (it will default to patches at darcs.net and wind up in
our patch tracker)
 
> What is worse, I cannot use emacs and darcsum-mode for this, because
> darcs will fail in "whatsnew". For me, this problem is very real,
> because it breaks my "/etc" repo and three other working projects.

Even if the boring trick above works?

I'm not saying that users should *have* to use boring workaround; I just
want to make sure I have an accurate assessment of the damage.

> Considering the fact that symlinks are not properly handled by darcs (could
> not be version-controlled) I personally see no benefits in new behavoir, but
> see several nasty regressions + potential for more.

Sounds right...

> > 2. Do we have test cases?  Yes,
> > tests/failing-issue1645-ignore-symlinks.sh (I'm really bad about asking
> > for tests which actually already exist).
> >
> 
> Command "runghc Setup.lhs test failing-issue1645-ignore-symlinks" fails for
> me with the following:
> 
> rm -rf R S                      # Another script may have left a mess.
> + rm -rf R S
> darcs init      --repo R S      # Create our test repos.
> + darcs init --repo R S
> 
> darcs failed:  Bad argument: `S'

Ouch! The test was failing for the wrong reason; good catch.  I've
updated the test accordingly and now I think it fails for the right
reason.

> > 3. Has the code for it been reviewed.  Petr: I think you may have
> > forgotten to push your post hashed-storage 0.4.10 patches, so nobody can
> > review them.

This one may be the key blocker as I suspect the 0.4.11 code is just on
Petr's laptop :-P

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.osuosl.org/pipermail/darcs-devel/attachments/20100401/21712f85/attachment.pgp>