a perl script crashed my mac!

[ioneabu]

I have a directory with about 15000 files. About 11000 have .txt
extensions. The files are saved in a directory on an external usb2
hard drive connected to my iBook G4 running OS X 10.4.

I wanted to clear out any files that were not .txt. I ran this script:

#!/usr/bin/perl

use strict;
use warnings;

my $dir = $ARGV[0]; #directory to search under
use File::Find;
find(\&wanted, $dir);

sub wanted
{
unlink if not /\.txt$/
}

Within less than a second, my screen went to a darker shade and a
message appeared telling me that I must turn off my computer by holding
down the power button. I have never seen an OS X computer crash until
now. I repeated the process with the same outcome.

Thanks!

wana

 

[John W. Krahn]

I have a directory with about 15000 files. About 11000 have .txt
extensions. The files are saved in a directory on an external usb2
hard drive connected to my iBook G4 running OS X 10.4.

I wanted to clear out any files that were not .txt. I ran this script:

#!/usr/bin/perl

use strict;
use warnings;

my $dir = $ARGV[0]; #directory to search under
use File::Find;
find(\&wanted, $dir);

sub wanted
{
unlink if not /\.txt$/
}

Within less than a second, my screen went to a darker shade and a
message appeared telling me that I must turn off my computer by holding
down the power button. I have never seen an OS X computer crash until
now. I repeated the process with the same outcome.

It could be because you are trying to unlink directories.

perldoc -f unlink
unlink LIST
unlink Deletes a list of files. Returns the number of files
successfully deleted.

$cnt = unlink 'a', 'b', 'c';
unlink @goners;
unlink <*.bak>;

Note: "unlink" will not delete directories unless you are
superuser and the -U flag is supplied to Perl. Even if these
conditions are met, be warned that unlinking a directory can
inflict damage on your filesystem. Use "rmdir" instead.

If LIST is omitted, uses $_.


Use the file test operators to ensure that only files are being unlinked.

perldoc -f -X


John

 

[Christopher Nehren]

I have a directory with about 15000 files. About 11000 have .txt
extensions. The files are saved in a directory on an external usb2
hard drive connected to my iBook G4 running OS X 10.4.

I wanted to clear out any files that were not .txt. I ran this script:

#!/usr/bin/perl

use strict;
use warnings;

my $dir = $ARGV[0]; #directory to search under
use File::Find;
find(\&wanted, $dir);

sub wanted
{
unlink if not /\.txt$/
}

Within less than a second, my screen went to a darker shade and a
message appeared telling me that I must turn off my computer by holding
down the power button. I have never seen an OS X computer crash until
now. I repeated the process with the same outcome.

It could be because you are trying to unlink directories.

If attempting to unlink a directory caused the kernel to panic, then I
pity Mac users.

I'd personally solve this problem like so (no real need for perl):

find . -type f -maxdepth 1 -not -iname '*.txt' -print0 | xargs -0 rm

Execute this from within the directory containing the files to remove.
You can remove the -print0 and -0 if your file names don't contain
spaces or other nasty characters (mostly shell metacharacters).

Best Regards,
Christopher Nehren

 

[John]

Christopher wrote:

"If attempting to unlink a directory caused the kernel to panic, then I

pity Mac users. "

That's probably not the whole story. What if the OP was inadvertently
trying to unlink the directory containing the script? Or the script
file itself?

But that, I suppose, would not be reproducible

John C.

 

[Josef Moellers]

Christopher wrote:

"If attempting to unlink a directory caused the kernel to panic, then I

pity Mac users. "

That's probably not the whole story. What if the OP was inadvertently
trying to unlink the directory containing the script? Or the script
file itself?

But that, I suppose, would not be reproducible

"To make an assumption means to fool yourself"

The OP has supplied little information, e.g. he hasn't named the name of
the directory (could have been important) he hasn't described whether
any files were deleted at all, ...
He could have reproduced the problem by re-typing the script (it was
little more than a one-liner)!

 

[lusol]

I have a directory with about 15000 files. About 11000 have .txt
extensions. The files are saved in a directory on an external usb2
hard drive connected to my iBook G4 running OS X 10.4.

I wanted to clear out any files that were not .txt. I ran this script:

#!/usr/bin/perl

use strict;
use warnings;

my $dir = $ARGV[0]; #directory to search under
use File::Find;
find(\&wanted, $dir);

sub wanted
{
unlink if not /\.txt$/
}

Within less than a second, my screen went to a darker shade and a
message appeared telling me that I must turn off my computer by holding
down the power button. I have never seen an OS X computer crash until
now. I repeated the process with the same outcome.

Well, the quoted program - with high probability - did NOT cause your
kernel panic because it doesn't compile, let alone execute.

So you need to tell the entire story ...

Steve

 

[Anno Siegel]

I have a directory with about 15000 files. About 11000 have .txt
extensions. The files are saved in a directory on an external usb2
hard drive connected to my iBook G4 running OS X 10.4.

I wanted to clear out any files that were not .txt. I ran this script:

#!/usr/bin/perl

use strict;
use warnings;

my $dir = $ARGV[0]; #directory to search under
use File::Find;
find(\&wanted, $dir);

sub wanted
{
unlink if not /\.txt$/
}

Within less than a second, my screen went to a darker shade and a
message appeared telling me that I must turn off my computer by holding
down the power button. I have never seen an OS X computer crash until
now. I repeated the process with the same outcome.

Well, the quoted program - with high probability - did NOT cause your
kernel panic because it doesn't compile, let alone execute.

What problems do you see with the code? I don't see any.

Anno

 

[ioneabu]

Christopher wrote:

"If attempting to unlink a directory caused the kernel to panic, then I

pity Mac users. "

That's probably not the whole story. What if the OP was inadvertently
trying to unlink the directory containing the script? Or the script
file itself?

But that, I suppose, would not be reproducible

John C.

It is likely that the problem was caused by attempting to unlink a
directory. I don't know if the crash would have occurred if I was not
working on the external drive.

Is it possible that even if there were no directories contained in the
working directory that my program would have worked on . and .. and
treated them as directories?

The script was outside of the working directory and was uneffected by
its own actions.

I hate to try it again on my iBook. It's depressing to see it crash.
A flashback to the old days of my Mac SE that I put bad memory chips
into and saw the very saddening 'sad mac'.

wana

 

[lusol]

I have a directory with about 15000 files. About 11000 have .txt
extensions. The files are saved in a directory on an external usb2
hard drive connected to my iBook G4 running OS X 10.4.

I wanted to clear out any files that were not .txt. I ran this script:

#!/usr/bin/perl

use strict;
use warnings;

my $dir = $ARGV[0]; #directory to search under
use File::Find;
find(\&wanted, $dir);

sub wanted
{
unlink if not /\.txt$/
}

Within less than a second, my screen went to a darker shade and a
message appeared telling me that I must turn off my computer by holding
down the power button. I have never seen an OS X computer crash until
now. I repeated the process with the same outcome.

Well, the quoted program - with high probability - did NOT cause your
kernel panic because it doesn't compile, let alone execute.

What problems do you see with the code? I don't see any.

Via copy/aste, I get:

[lusol@dragonfly:/tmp] cat > frog
#!/usr/bin/perl

use strict;
use warnings;

my $dir = $ARGV[0]; #directory to search under
use File::Find;
find(\&wanted, $dir);

sub wanted
{
unlink if not \.txt$
}
[lusol@dragonfly:/tmp] emacs -nw

[1]+ Stopped emacs -nw
[lusol@dragonfly:/tmp] perl frog
syntax error at frog line 12, near "\."
Execution of frog aborted due to compilation errors.
[lusol@dragonfly:/tmp]


Perhaps missing characters when read via tin???

Anno

Steve

 

[Sherm Pendley]

It is likely that the problem was caused by attempting to unlink a
directory. I don't know if the crash would have occurred if I was not
working on the external drive.

I tried deleting a directory various different ways on my internal hd
using Perl's unlink() function, and I couldn't cause such a crash. Nor
was I surprised at that - frankly, I would have been surprised if such a
heinous bug *was* present in the core OS.

It's much more likely to be a bug in either the USB2 driver or the file
system driver.

Is the external device a "dual purpose" device that works on both Mac OS
X and Windows? If so, it's probably using FAT32. If that turns out to be
the case, and you don't care about Windows support, try reformatting the
drive with HFS+.

Otherwise, try repeating your experiment on an internal and/or Firewire
drive (if you have one).

sherm--

 

[John]

ione wrote:

Is it possible that even if there were no directories contained in the
working directory that my program would have worked on . and .. and
treated them as directories?

Doesn't seem possible. Like Christopher, I would tackle the original
problem from the shell.

I wouldn't have solved it as elegantly as he did, and I wouldn't have
covered all cases, but if there are no subdirectories to worry about,
this ought to work:

$ mkdir ../temp
$ mv *.txt ../temp
$ rm *
$ mv ../temp/* .
$ rmdir ../temp



- John C.

 

[Anno Siegel]

What problems do you see with the code? I don't see any.

Via copy/aste, I get:

[lusol@dragonfly:/tmp] cat > frog
#!/usr/bin/perl

use strict;
use warnings;

my $dir = $ARGV[0]; #directory to search under
use File::Find;
find(\&wanted, $dir);

sub wanted
{
unlink if not \.txt$

^^^^^^
I see the indicated bit differently.

}
[...]

Perhaps missing characters when read via tin???

Apparently. For me "\.txt$" is enclosed in //, which makes it a legal
pattern match.

Anno

 

[lusol]

(e-mail address removed) wrote:
I have a directory with about 15000 files. About 11000 have .txt

What problems do you see with the code? I don't see any.

Via copy/aste, I get:

[lusol@dragonfly:/tmp] cat > frog
#!/usr/bin/perl

use strict;
use warnings;

my $dir = $ARGV[0]; #directory to search under
use File::Find;
find(\&wanted, $dir);

sub wanted
{
unlink if not \.txt$

^^^^^^
I see the indicated bit differently.

}
[...]

Perhaps missing characters when read via tin???

Apparently. For me "\.txt$" is enclosed in //, which makes it a legal
pattern match.

OK, then it works as advertised. We thus need more info from the OP
because Mac OS X so rarely kernel faults. We assume the OP is not doing
this sudo'ed on system files

Thanks,

 

[ioneabu]

ione wrote:

Is it possible that even if there were no directories contained in the
working directory that my program would have worked on . and .. and
treated them as directories?

Doesn't seem possible. Like Christopher, I would tackle the original
problem from the shell.

I wouldn't have solved it as elegantly as he did, and I wouldn't have
covered all cases, but if there are no subdirectories to worry about,
this ought to work:

$ mkdir ../temp
$ mv *.txt ../temp
$ rm *
$ mv ../temp/* .
$ rmdir ../temp



- John C.

That is precisely the way I solved the problem after two consecutive
crashes with the script. I agree with everyone that the OS X kernel is
not at fault and certainly not Perl. The usb2 driver explanation seems
most likely.

I appreciate the interest in this unusual episode so I am going to
reproduce the experiment in a more controlled way, using two different
models of external hard drives, one with usb2 only and one with usb2
and firewire. I will attempt to unlink a single directory and see if
it happens. Then I will try with both drives, using usb2 and firewire
on the one that has both. I'll document my finding here later.

wana