On Tue, 17 Jun 2014 11:03:00 +0200 (CEST)
Harald Barth wrote:
> Should we not just make a ".." in this situation?
I'm not sure if making that just a warning is a good idea or not, but
that shouldn't happen on just missing a ".." entry. You might want to
salvage the volume with -salvagedirs, sinc
On Tue, 17 Jun 2014 15:01:42 +0200 (CEST)
Harald Barth wrote:
>
>
> Well, I did add a patch like:
>
>
> Index: openafs-1.6.9/src/vol/vol-salvage.c
> ===
> --- openafs-1.6.9.orig/src/vol/vol-salvage.c2014-06-12 08:30:48.00
Well, I did add a patch like:
Index: openafs-1.6.9/src/vol/vol-salvage.c
===
--- openafs-1.6.9.orig/src/vol/vol-salvage.c2014-06-12 08:30:48.0
+
+++ openafs-1.6.9/src/vol/vol-salvage.c 2014-06-17 10:34:23.857444175
On Tue, 17 Jun 2014 10:25:21 +0200 (CEST)
Harald Barth wrote:
>
> http://git.openafs.org/?p=openafs.git;a=commitdiff;h=e8faeae6dcae0e566de2b21d53d3f78f3cc44e3f
>
> > Improve JudgeEntry() detection of orphaned directories to
> > prevent unintentional deletion of their '.' and '..' entries.
> > T
> This change went into 1.6.6, so 1.6.7 would do as well.
Thanks. Built myself a 1.6.9 from the source deb from unstable.
But unfortunately, the volume in question breaks the 1.6.9 salvageserver as
well :(
Gdb tells me:
(gdb) up
#1 0x7f82c1a436f0 in abort () from /lib/x86_64-linux-gnu/lib
On 2014-06-17, at 10:25, Harald Barth wrote:
> More from the core:
>
> (gdb) bt
> #0 0x7fbe95040475 in raise () from /lib/x86_64-linux-gnu/libc.so.6
> #1 0x7fbe950436f0 in abort () from /lib/x86_64-linux-gnu/libc.so.6
> #2 0x0042f162 in osi_Panic (
>msg=msg@entry=0x4635f0
More from the core:
(gdb) bt
#0 0x7fbe95040475 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x7fbe950436f0 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x0042f162 in osi_Panic (
msg=msg@entry=0x4635f0 "assertion failed: %s, file: %s, line: %d\n")
at ./../rx