Bk relink fails with 3rdParty/HiStorAPI-5.11.0.3981

(From our-ref D128468)

This was perhaps our last commercial case with bk support. I don’t think Larry applied his fix. On email, Wayne mentioned having to “hunt it down or reproduce it”, which sounds painfully like he might not have easy access to the information below, which I think we’d be happy to share publicly.

-----Original Message-----
From: Martin Dorey 
Sent: Friday, February 03, 2017 09:30
...
Subject: RE: bk relink fails with 3rdParty/HiStorAPI-5.11.0.3981

> If you want a trial release with these diffs I can do that so you guys can keep going.

I think it's just cosmetic for us, at worst a time/space performance thing and a distraction.  One other user noticed it, that I know of, but he wasn't interested enough to copy himself on our internal bug report.

-----Original Message-----
From: lm@bitkeeper.com [mailto:lm@bitkeeper.com] 
Sent: Friday, February 03, 2017 09:10
...
Subject: RE: bk relink fails with 3rdParty/HiStorAPI-5.11.0.3981

So these diffs "fix" it.  We need to think about it a bit, I have a feeling that 
the remap.c code expects the file to be there, hence the assert, so I need to work
backwards and see how we didn't figure out that we shouldn't have gotten to the
lstat.

If you want a trial release with these diffs I can do that so you guys can keep going.

slovax ~/bk/dev-oss-relink/src bk -Uc diffs
===== t/t.relink 1.27 vs edited =====
--- 1.27/src/t/t.relink 2016-05-17 11:45:32 -07:00
+++ edited/src/t/t.relink       2017-02-03 08:56:38 -08:00
@@ -187,3 +187,27 @@
 bk _cp SCCS/s.ff 2
 cmpfiles 1 2
 echo OK
+
+echo $N Bluearcs relink bug .........................................$NL
+cd "$HERE"
+mkdir bluearc
+cd bluearc
+bk setup a
+cd a
+mkdir -p foo/bar
+touch foo/bar/baz
+bk -xr new $Q
+bk commit -f $Q
+cd ..
+bk clone $Q a b
+cd b
+bk rmdir foo/
+mkdir quux
+touch quux/badger
+ln -s quux foo
+bk -xr new $Q
+bk commit -f $Q
+cd ..
+bk relink $Q a b || exit 1
+echo OK
+
===== remap.c 1.38 vs edited =====
--- 1.38/src/remap.c    2016-02-25 14:20:36 -08:00
+++ edited/src/remap.c  2017-02-03 08:56:01 -08:00
@@ -116,7 +116,11 @@
        char    buf[MAXPATH];
 
        sccs = fullRemapPath(buf, proj, rel);
-       assert(sccs);
+       //assert(sccs);
+       unless (sccs) {
+               bzero(sb, sizeof(struct stat));
+               return (-1);
+       }
        return (lstat(buf, sb));
 }

The fix for this has been pushed to bk://bkbits.net/bk/dev

I pretty much used Larry’s fix. It is somewhat hacky. I think the correct fix is to the function fslayer.c:fp_find() so that a pathname of repo/dir1/dir2/SCCS/s.file returns a correct relative pathname including the SCCS/s.file when dir2 is a symlink to a directory that doesn’t have a SCCS subdirectory. However, all attempts to make a change like that were a mess and broke many other regressions.