lcwakeman wrote on Thu, Oct 28, 2010 at 08:07:12 -0700:
>
> Actually, the hex editor that I finally found that could read the file before
> exhausting memory wouldn't allow me to copy the hex code. The periods in
> the example are null bytes (00). The rest are 7 bit ascii characters, space
> is 20...
>
Please try to use xxd then. It's important that we see exactly (at the
byte level) what happened. Chances are that xxd has abeen ported to
your platform.
(That's just the hex dump tool I'm used to, by the way. Other tools may
work too. Or even a quick-and-dirty script in C...)
>
>
> Daniel Shahaf-2 wrote:
> >
> > Can you provide a hex dump of what you just pasted? At the level the
> > bug is occurring in, it's important for us to have the actual bytes.
> >
> > 0000000: 4865 7265 2773 2061 6e20 6578 616d 706c Here's an exampl
> > 0000010: 6520 6f66 2074 6865 2066 6f72 6d61 7420 e of the format
> > 0000020: 7765 206e 6565 642e 2020 2849 2075 7365 we need. (I use
> > 0000030: 6420 7878 6428 3129 2074 6f20 7072 6f64 d xxd(1) to prod
> > 0000040: 7563 650a 7468 6973 2e29 0a uce.this.).
> >
> > Thanks,
> >
> > Daniel
> >
> > lcwakeman wrote on Wed, Oct 27, 2010 at 17:12:33 -0700:
> >>
> >> Using a hex editor, i found the bad node:
> >>
> >> id: hkh-3.0.r3/1147375416.type: file.count: 0.text: 2 18255002 89 76
> >> a62e181985b9f0188358520286e7f3cf de9e9fa50eb1d5cbaae57a82ddfc20e398a8ed9b
> >> 2-2/_ki0.props: 3 1147375350 53 0
> >> 113136892f2137aa0116093................................................ignedDocument.gif.copyroot:
> >> 0 /..PLAIN.K 13.svn:mime-type.V 24.application/octet-stream.END.ENDREP.
Are ALL fourty-eight dots NUL bytes? Or is the first of them a newline
(0x0A) byte?
> >>
Thankfully, the headers always come in the same order: props, cpath,
copyfrom, copyroot. The cpath and copyfrom path indicate that the node
has been copied.
Is that correct? Was *ignedDocument.gif indeed copied in that revision?
From where? (repository-relative path and revision)
Received on 2010-10-28 18:04:07 CEST