HORIBLE EVIL BUG, Wrecks computer

[bfc]

The few posts about terminal.app not working are a result of this.

I have found a HORIBLE EVIL BUG in MacOSX!! All of these files have ben some zeroed out, they dont have a file size! Other people are reporting the problem on macosx.com but i'm afraid this might happen to alot more people as time goes on. I first noticed it when i started up Terminal.app and it said "[Prossess compleated]". You cannot copy the files from the cd, i cant chown them anyways! People have tried to reinstall but only left with a formated HD and lots of frustration! Someone HELP!

Some files that have been whiped out:
bfc% ls -la /usr/sbin | grep " 0 "
-rwxrwxrwx 1 root wheel 0 Sep 25 17:39 chown

bfc% ls -la /usr/bin | grep " 0 "
-rwxrwxrwx 1 root wheel 0 Sep 25 17:39 arch
-rwxrwxrwx 1 root wheel 0 Sep 25 17:42 at
-rwxrwxrwx 1 root wheel 0 Sep 25 17:42 atq
-rwxrwxrwx 1 root wheel 0 Sep 25 17:42 atrm
-rwxrwxrwx 1 root wheel 0 Sep 25 17:42 batch
-rwxrwxrwx 1 root wheel 0 Sep 25 17:42 chfn
-rwxrwxrwx 1 root wheel 0 Sep 25 17:39 chgrp
-rwxrwxrwx 1 root wheel 0 Sep 25 17:42 chpass
-rwxrwxrwx 1 root wheel 0 Sep 25 17:42 chsh
-rwxrwxrwx 1 root wheel 0 Sep 25 17:42 cksum
-rwxrwxrwx 1 root wheel 0 Sep 25 17:42 compress
-rwxrwxrwx 1 root wheel 0 Sep 25 17:39 cpio
-rwxrwxrwx 1 root wheel 0 Sep 25 17:42 emacs
-rwxrwxrwx 1 root wheel 0 Sep 25 17:42 emacs-20.7
-rwxrwxrwx 1 root wheel 0 Sep 25 17:39 ex
-rwxrwxrwx 1 root wheel 0 Sep 25 17:42 gawk
-rwxrwxrwx 1 root wheel 0 Sep 25 17:42 gawk-3.0.4
-rwxrwxrwx 1 root wheel 0 Sep 25 17:42 groups
-rwxrwxrwx 1 root wheel 0 Sep 25 17:42 gunzip
-rwxrwxrwx 1 root wheel 0 Sep 25 17:42 gzcat
-rwxrwxrwx 1 root wheel 0 Sep 25 17:42 gzip
-rwxrwxrwx 1 root wheel 0 Sep 25 17:42 hexdump
-rwxrwxrwx 1 root wheel 0 Sep 25 17:42 id
-rwxrwxrwx 1 root wheel 0 Sep 25 17:39 machine
-rwxrwxrwx 1 root wheel 0 Sep 25 17:42 od
-rwxrwxrwx 1 root wheel 0 Sep 25 17:39 perl
-rwxrwxrwx 1 root wheel 0 Sep 25 17:39 perl5.6.0
-rwxrwxrwx 1 root wheel 0 Sep 25 17:39 reset
-rwxrwxrwx 1 root wheel 0 Sep 25 17:42 sum
-rwxrwxrwx 1 root wheel 0 Sep 25 17:39 tar
-rwxrwxrwx 1 root wheel 0 Sep 25 17:42 texi2html
-rwxrwxrwx 1 root wheel 0 Sep 25 17:39 tset
-rwxrwxrwx 1 root wheel 0 Sep 25 17:42 uncompress
-rwxrwxrwx 1 root wheel 0 Sep 25 17:42 uptime
-rwxrwxrwx 1 root wheel 0 Sep 25 17:39 vi
-rwxrwxrwx 1 root wheel 0 Sep 25 17:39 view
-rwxrwxrwx 1 root wheel 0 Sep 25 17:42 w
-rwxrwxrwx 1 root wheel 0 Sep 25 17:42 whoami
-rwxrwxrwx 1 root wheel 0 Sep 25 17:42 zcat
-rwxrwxrwx 1 root wheel 0 Sep 25 17:42 zcmp
-rwxrwxrwx 1 root wheel 0 Sep 25 17:42 zdiff

bfc% ls -la /bin | grep " 0 "
-rwxrwxrwx 1 root wheel 0 Sep 25 17:39 [
-rwxrwxrwx 1 root wheel 0 Sep 25 17:39 csh
-rwxrwxrwx 1 root wheel 0 Sep 25 17:39 pax
-rwxrwxrwx 1 root wheel 0 Sep 25 17:39 test

bfc% ls -la /bin | grep " 0 "
-rwxrwxrwx 1 root wheel 0 Sep 25 17:39 [
-rwxrwxrwx 1 root wheel 0 Sep 25 17:39 csh
-rwxrwxrwx 1 root wheel 0 Sep 25 17:39 pax
-rwxrwxrwx 1 root wheel 0 Sep 25 17:39 test

[parody]

Did you perchance try that hack in which you can run the OS 9 Finder in OS X after changing Finder's file type to APPL in ResEdit?

Apparently, if your OS 9 System Folder is on the same partition as OS X, running the OS 9 Finder as a Classic app zeroes out some OS X stuff, starting with /bin/tcsh, and spreading from there. There may well be other ways of awakening this bug.

Someone else reported that doing this hack doesn't zero these OS X files when the OS 9 Finder/System Folder is on a separate partition from OS X.



http://www.deja.com/getdoc.xp?AN=679973183

[bfc]

I did dubble click on the finder once but i didnt notice the problem tell a few days after, and after a few restarts... this could posibly be the cause, Thanx for your comment.

[HiperMac]

I took a look around and I noticed that there are files that are considered o size .... when I look at the same file with the gui interface and I inspect them with the inspector they all come up with something around 32 ks ..... uhmmmmmmmmmmm

Can it be the way file size is read???

I did not use finder as an app....I think so.

Thanks

[LunaMorena]

Originally posted by HiperMac
I took a look around and I noticed that there are files that are considered o size .... when I look at the same file with the gui interface and I inspect them with the inspector they all come up with something around 32 ks ..... uhmmmmmmmmmmm

Can it be the way file size is read???

Well in this case, the Mac OS and a *nix system read file sizes differently. The Mac OS reads up how much space it takes on the drive while the BSD system reads how big the file actually is.

Sound confusing? Well the reason is that the HD is divided up into little pieces called "blocks". How big these are under HFS and HFS+ depend directly on how big your hard drive is, because it is divided into a set number of blocks. HPFS+ has more blocks than HFS; that's the main difference between the two. You cannot put more than one file in a block but each file can take up more than one block.

So for instance each block on my hard drive is about 4k. if I have a 15k file, it will take up 4 of those blocks. The Mac will report the size as 16k since that's how big 4 blocks are, and the BSD system will report the size as 15k. A 0 k file, since it exists will still take up a block, so the mac OS will still report it as 4k (or however big one block is on your system).

Which method of reporting is better? Well, the Mac is a more accurate measure of how much space each file occupies ON YOUR SYSTEM, but if you ever plan on transferring the file to another system, the BSD reporting is more accurate, since the other system may have different-sized blocks.

[bongoherbert]

For what it is worth, it is probably a good idea to not confuse correlation with causation- to wit- I have had the same thing happen and I had not even heard about the res edit hack until I looked at this board.

I have a bunch of 0-length files right at this moment and, to the best of my memory, I can't even remember running Classic on this machine...

[macavenger]

It doesn't make sense to me, but I have been having this problem for several restarts. Then I ran Norton speed disk 6.0b45, and the next time I restarted my computer all the file sizes were back to normal, and have been fine ever since. Did SpeedDisk fix the problem, or was it just coincidence that the problem fixed itself after I ran Speed disk? it did not happen with earlier versions of speed disk.

[parody]

Originally posted by bongoherbert
For what it is worth, it is probably a good idea to not confuse correlation with causation- to wit- I have had the same thing happen and I had not even heard about the res edit hack until I looked at this board.

I have a bunch of 0-length files right at this moment and, to the best of my memory, I can't even remember running Classic on this machine...

By the way, that's why I included these words in my original post: "There may well be other ways of awakening this bug."

That said, it is worth reiterating that I am confident that the actions I described in my first reply do indeed directly result in the immediate appearance of zero length files. Further details may be found in the URL I supplied in that reply.

But how and why remain the open questions. The fact that another person has reported that the file sizes get automagically repaired after running Speed Disk is intriguing. Perhaps this suggests the bug is really symptomatic of a filesystem problem. I would expect the typical user to run Disk Doctor before applying Speed Disk, and perhaps Disk Doctor patched things up...