On Wed, Nov 21, 2007 at 10:20:39PM +1300, Richard Toohey wrote:
> On 21/11/2007, at 12:08 PM, Jeff Ross wrote:
>
>> Jeff Ross wrote:
>>> Hi,
>>>
>>> "
>>> 11609 restore RET write 27/0x1b
>>> 11609 restore CALL write(0x2,0x80147000,0x34)
>>> 11609 restore GIO fd 2 wrote 52 bytes
>>> "1834488 Document Scrap '\M-o\M^C\M^X Journal Entrie...'.shs
>>> "
>>> On a console (not xterm) the file name appears to be
>>> Document Scrap 'C/ Journal Entrie...'.shs
>>> (that's a lower case "i" with two dots over it.)
>>
>> My original e-mail did get mangled a little.
>>
>> The C/ above is really the lowercase i with two dots over it.
>>
>> Jeff
>
> I had a look out of curiosity (again) ... no great words of wisdom but
> might help ...
>
> Doesn't *just* seem to be because of the i-with-two-dots above it (0xEF? I
> looked at http://unicode.org/charts/ and the Latin-1 page - you'll need a
> PDF viewer. The character is a LATIN SMALL LETTER I WITH DIAERESIS to give
> it the proper moniker ...)
>
> Create char_file.c (yes, no prizes for this code.) You can achieve getting
> this filename without code, but might be easier to use the code than find
> the right character and paste it.
>
> #include <stdio.h>
>
> int main(void) {
> FILE *f;
> char fn[]="xxxxx.txt";
> fn[2]=0xEF;
> f=fopen(fn,"w");
> fputs("Something here",f);
> fclose(f);
> return 0;
> }
>
> Compile with ...
> # cc -Wall -o char_file char_file.c
>
> Execute with ...
> # ./char_file
>
> You should end up with a new file in your current directory:
>
> xx?xx.txt (depending on your display, that question mark may
> appear as the
> i-with-two-dots.)
>
> Do a dump:
>
> # mkdir testd
> # mv xx?xx.txt testd
> # dump -0 -f testd.dmp testd/
> DUMP: Dumping sub files/directories from /home
> DUMP: Dumping file/directory testd/
> DUMP: Date of this level 0 dump: Thu Nov 22 10:59:25 2007
> DUMP: Date of last level 0 dump: the epoch
> DUMP: Dumping /dev/rwd0h (/home) to testd.dmp
> DUMP: mapping (Pass I) [regular files]
> DUMP: mapping (Pass II) [directories]
> DUMP: estimated 106 tape blocks on 0.00 tape(s).
> DUMP: Volume 1 started at: Thu Nov 22 10:59:25 2007
> DUMP: dumping (Pass III) [directories]
> DUMP: dumping (Pass IV) [regular files]
> DUMP: 74 tape blocks on 1 volume
> DUMP: Date of this level 0 dump: Thu Nov 22 10:59:25 2007
> DUMP: Volume 1 completed at: Thu Nov 22 10:59:25 2007
> DUMP: Date this dump completed: Thu Nov 22 10:59:25 2007
> DUMP: Average transfer rate: 0 KB/s
> DUMP: Closing testd.dmp
> DUMP: DUMP IS DONE
>
> Do a restore:
>
> # restore -i -f testd.dmp
> restore > cd testd
> restore > verbose
> verbose mode on
> restore > ls
> ./testd:
> 25 ./ 2 ../ 24 xx?xx.txt
>
> restore > quit
>
> The copy/paste was via a Mac console - on X running on OpenBSD 4.2/i386 the
> i-with-two-dots appears correctly throughout.
>
> I *know* your dump/restore process is a LOT more complicated than this -
> I'm trying to reproduce the error with the smallest amount of effort (don't
> fancy setting up a Windows box and compressing 12Gb, etc.!)
>
> Guess the next thing might be getting a way smaller sample dump file that
> still shows the problem? Doesn't *seem* to be just the i character - so is
> it the spaces? The apostrophes? Combination of all three? The length of
> the filename? The Windows factor? Samba? Translation by something?
>
> The (interactive) restore source code is in
> /usr/src/sbin/restore/interactive.c - so you could try adding some debug
> messages in there on a test box and run the file through it ...
>
> Are you running 4.2 i386 (apologies if covered or obvious in your posting?)
>
> Thanks.
The easiest way to reproduce I found so far is:
echo '\M-o\M^C\M^X' | unvis
It hangs my xterm. It does not hang a console.
I think dump should 'vis' the filenames it prints.
-Otto
