copy - strange behaviour when using shell

[Raziel]

The command i'm using is "copy clone norep path:#? all to device:"

Has anyone encountered this strange behaviour?

When copying large numbers of files to a partition through the copy command and with Amigashell...at some point shell will output garbage or to be precise some other characters for the file/path name, like so
÷åáðïî­ðïìåáòí­óãïòðéïî®ðîç®óöî­÷ïòë®®ãïðéåä®
Happens to me everytime i copy back big partitions which i first backed up to another partition.

It doesn't matter if jxfs or sfs, seems to be either a shell or copy problem and it looks like as if some internal counter overflows.
This would also explain why the files are still copied fine and after the whole process is finished on restarting the copy command the files will be printed fine again until it rolls over to the strange chars again
It's not caused by asingle large file, because before this there were already MANY large files copied.

ajk: i agree, sounds like it starts reading supposed file names from somewhere that no longer contains them

I can repeat that behaviour and i can also see why it wasn't caught yet.
It happens only with VERY large numbers of files...i have one with 19.200 and one with over 20.000 files that trigger it

It's also no link that may cause it, both partitions only hold data files in differing sizes

[tonyw]

I'd really like to see the "before and after" of that line of crap. Presumably there are many lines of "<filename>..copied", followed by one or more lines of crap?

Does it recover and start printing properly again? Is it still crap when it finishes and returns to the command prompt? Can you copy and paste the output from the console window?

There are no "counters" associated with copying files that could overflow and corrupt filenames. The only thing I can think of is that the filenames are corrupted in the source directory, but you should be able to see that using the WB to open the directories involved.

[Raziel]

I'd really like to see the "before and after" of that line of crap. Presumably there are many lines of "<filename>..copied", followed by one or more lines of crap?

Does it recover and start printing properly again? Is it still crap when it finishes and returns to the command prompt? Can you copy and paste the output from the console window?

There are no "counters" associated with copying files that could overflow and corrupt filenames. The only thing I can think of is that the filenames are corrupted in the source directory, but you should be able to see that using the WB to open the directories involved.

It starts suddenly sometimes after a lot of files have been processed.
That makes it kind of hard to catch it, because i would need to stay around and catch the moment as i don't have a history in shell.
I can try with a redirection to a logfile

There is no corruption on either the source or the destination dir on those files, they are perfetly copied

Actually i think that shell is "simply" switching to another character set to display the copy information or it starts printing the information with a virtual pressed CTRL or Alt-CTRL or something.
I don't really know why it would do that though, but there is definitely no file corruption going on.

After the whole process finished as i wrote it gives control back to shell and displays a perfextly fine "13. AmigaOS:>"

edit: It still prints the same, but with other characters wich aren't even random

® = .
ã = c
ï = o
ð = p
é = i
å = e
ä = d
÷åáðïî ðïìåáòí óãïòðéïî®ðîç®óöî ÷ïòë®®ãïðéåä®
÷eápïî pïìeáòí ócïòppïî.pîç.óöî ÷ïòë..copied. (Sorry, haven't found out more)

It's like a copy protection from 80s amiga games

[thomasrapp]

You've probably got a file with an ASCII 14 (0x0e) character in it. This switches the console into "foreign character mode" or something like that. An ASCII 15 (0x0f) character or ESC [0m switches it back.

Try this ARexx program as a demonstration:

Code: Select all

/* rexx */
say "abcdef" d2c(14) "abcdef" d2c(15) "abcedf"

[Raziel]

You've probably got a file with an ASCII 14 (0x0e) character in it. This switches the console into "foreign character mode" or something like that. An ASCII 15 (0x0f) character or ESC [0m switches it back.

Try this ARexx program as a demonstration:

Code: Select all

/* rexx */
say "abcdef" d2c(14) "abcdef" d2c(15) "abcedf"

Yes, exactly like it

rx 'say "..copied." d2c(14) "..copied." d2c(15) "..copied."'
..copied.  ®®ãïðéåä®  ..copied.


You found the enigma

But shouldnt the console ignore such a file when copy is processing it?
I mean i have lots of data files and one of them seems to be such an ASCII 14 file AND being processed while the copy operation, but it shouldn't, should it?

To be perfectly honest, it scared the hell out of me when i first saw it and i thought, great, corrupted data

[tonyw]

But you're not copying the content of the file to the console, are you? You're only printing the filenames to the console.

That suggests that it's one of the filenames that contains the SI character, not the file itself. You can always stop the process by typing Ctrl-C when it goes bad, then you could check the last few files to narrow down the search.

I can't test this here because I get an error when I try to run that script:
Command returned 5/1: Program not found

I have a file test.rx which contains 'say "abcdef" d2c(14) "abcdef" d2c(15) "abcedf"'

But I get the error when I type 'rx test.rx'. I've never used Arexx so please tell me how to make the script work. I need to test this problem with the new console.

[Raziel]

But you're not copying the content of the file to the console, are you? You're only printing the filenames to the console.

No, just a simple copy operation where "copy" is telling me what file is copyied

Put this

Code: Select all

/* rexx */
say "..copied." d2c(14) "..copied." d2c(15) "..copied."

in a file called test.rx and in a shell simply do a
rx test.rx

The '' are only to distinguish between rexx commands when using them under shell or when using os commands in an arexx script.

Though
rx 'say "..copied." d2c(14) "..copied." d2c(15) "..copied."'
should work for you in shell too

[Raziel]

Found them

I have PrBoom installed and for some reason there are a few 0 byte files with corrupted filenames

GL empty ----rw-d 02-Dec-04 12:37:30
g< empty ----rw-d 29-Nov-04 19:40:54
ux empty ----rw-d 02-Dec-04 12:26:28
20 3808 ----rwed 26-Feb-80 07:16:00
è, empty ----rw-d 18-Nov-04 14:12:48
F
empty ----rw-d 09-Nov-04 18:54:12
F<Pãh empty ----rw-d 09-Nov-04 18:39:39
Åä                          åíðôù ­­­­ò÷­ä °±­Äåã­°´ ±·ºµ¶º°µ
âÔ                          åíðôù ­­­­ò÷­ä °±­Äåã­°´ ±³º°¸º°³
¾´                          åíðôù ­­­­ò÷­ä ²·­Îïö­°´ ±·º°²º´¸
÷                          åíðôù ­­­­ò÷­ä ²·­Îïö­°´ ±¹º°°º³´
öèï                      åíðôù ­­­­ò÷­ä ²·­Îïö­°´ ±¸º´µº±³
ý·¼                          åíðôù ­­­­ò÷­ä ±³­Îïö­°´ ²°º±´º´±
üÝÄ                          åíðôù ­­­­ò÷­ä ±²­Îïö­°´ ±²º´²º²²

which will also change the list and dir command output (as seen above) when using them on that directory

edit: it doesn't happen when i redirect the output to a file

ü]Ä..skipped (already exists).
ý7<..skipped (already exists).
öè†o€..skipped (already exists).
÷œ..skipped (already exists).
>4..skipped (already exists).
bT..skipped (already exists).
Åd..skipped (already exists).
È4..skipped (already exists).
È|嫀..skipped (already exists).
t..skipped (already exists).
F<Pãh..skipped (already exists).
F„..skipped (already exists).
è,..skipped (already exists).
G(ux..skipped (already exists).
g<..skipped (already exists).
GL..skipped (already exists).

[nbache]

Though
rx 'say "..copied." d2c(14) "..copied." d2c(15) "..copied."'
should work for you in shell too

I think (although I didn't test it) that you'd want to swap single and double quotes in that example. The shell only recognizes double quotes, while ARexx treats single and double quotes equivalent, so the double quotes should be around the whole ARexx onliner.

Best regards,

Niels

[tonyw]

Actually, a cut 'n' paste from that last quote shows the problem just fine.

What happens is that the console (once it has received the SO (Shift Out) character), adds 0x80 to every character before it is displayed, thus in effect selecting an alternate character set. This state is reset by a SI (Shift In) issued by the Shell before every command prompt.

Thanks.