Re: Strange behavior while copying files
> Hi, I'm trying to copy a large directory /sub to a partition mounted
> on /local. /sub contains a functioning Hurd filesystem produced
> from the initial tarball. I used this command
>
> # cd /sub
> # cp -a * /local/
Use -v to see each action cp is doing.
> First, it's very slow, but that's a known problem. After a while it
> spurts out these messages and finishes:
>
> cp: cannot create regular file `/local/servers/exec': Computer bought the farm
Try to reproduce this with actions just on this single file. Most likely
the filesystem for /local crashed. I'm presuming it's ext2fs, but this is
something you should spell out in a problem report (i.e. include
"showtrans /local").
The following "Read-only filesystem" errors are probably just what they
say: the /local filesystem has been mounted read-only. This is the normal
case if the filesystem crashed and then a new one was started
(automatically by the passive translator setting on /local) without running
fsck in between (which of course you hadn't). There should be some
messages sent to the filesystem's stderr about this, or to /dev/console if
the filesystem is root and was started without a stderr (the normal case
for passive translators).
> The strange thing happens when this is done, if I look in my
> / I have a ton of pty* and tty* device files created there, even though
> I copied no files to or from /.
This I cannot explain. I tend to be a little skeptical that this really
happened the way it appeared to you, since it's the only part of the
scenario that is not readily explained by known behavior and understandable
bugs. Please try to reproduce the failure under controlled conditions.
> Why does this happen? Also if I can run a debug version of the ext2fs
> server on /local, where should I set a breakpoint to catch this?
EIEIO usually indicates that the server crashed. So if you were running it
under gdb, you would probably catch the fatal exception without setting any
breakpoints. (It never hurts to set a breakpoint on _exit or __task_terminate
just in case, so you can always do a backtrace and see what code path led
to the process killing itself.)
Reply to: