scjones@sdrc.UUCP (Larry Jones) (01/16/89)
OK, I've got one for you guys. I've got this file that just absorbs whatever get put into it. For example, if I do: ls -l >blackhole ; cat blackhole I get nothing. ls -l blackhole shows it has a reasonable size, but even od just shows a few zeros. If I do this with a different file, it works like you would expect. If I delete blackhole and try it again, I get the same results (I also get the same inode for the file, which I suspect is critical). My first thought was a munged file system, but fsck shows all is well. Anyone have any idea what is going on here??? ---- Larry Jones UUCP: uunet!sdrc!scjones SDRC scjones@sdrc.UU.NET 2000 Eastman Dr. BIX: ltl Milford, OH 45150 AT&T: (513) 576-2070 "When all else fails, read the directions."
rogers@ofc.Columbia.NCR.COM (H. L. Rogers) (01/16/89)
In article <498@sdrc.UUCP> scjones@sdrc.UUCP (Larry Jones) writes: > > ls -l >blackhole ; cat blackhole > >I get nothing. ls -l blackhole shows it has a reasonable size, >but even od just shows a few zeros. Uh, it works on my 5.2 system. File blackhole shows 0 size for itself, but an ls -l of the parent directory reveals a size equivalent to the number of characters sent to the screen from the ls -l command. -- HL Rogers (hl.rogers@ncrcae.Columbia.NCR.COM)
debra@alice.UUCP (Paul De Bra) (01/17/89)
In article <498@sdrc.UUCP> scjones@sdrc.UUCP (Larry Jones) writes: }OK, I've got one for you guys. I've got this file that just }absorbs whatever get put into it. For example, if I do: } } ls -l >blackhole ; cat blackhole } }I get nothing. ls -l blackhole shows it has a reasonable size, }but even od just shows a few zeros. If I do this with a }different file, it works like you would expect. If I delete }blackhole and try it again, I get the same results (I also get }the same inode for the file, which I suspect is critical). } Sounds like you have a brain-damaged shell that treats "blackhole" as a name for /dev/null. If you do "ls -l >/dev/null ; cat /dev/null" you get nothing. ls -l /dev/null shows a reasonable size because /dev/null is a character device and the "size" field is actually the minor device number and not the size. The suspicious part is that when you remove blackhole and try again you get the same result. This makes me believe your shell does something magic (i.e. stupid) with the name blackhole. Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
john@chinet.chi.il.us (John Mundt) (01/17/89)
In article <498@sdrc.UUCP> scjones@sdrc.UUCP (Larry Jones) writes: >OK, I've got one for you guys. I've got this file that just >absorbs whatever get put into it. For example, if I do: > ls -l >blackhole ; cat blackhole >I get nothing. ls -l blackhole shows it has a reasonable size, >but even od just shows a few zeros. If I do this with a >different file, it works like you would expect. Is blackhole linked to /dev/null? I'd like to see the actual output from ls -l. Of course, Hawkings has postulated mini-blackholes and one might be living on the top of your hard disk, though it ought to play havoc with the head as it passes over. Also, be forewarned that he thinks they can evaporate over time because of angular momentum, and would take out a fair sized city when they do. I doubt if it is covered under warranty. -- --------------------- John Mundt Teachers' Aide, Inc. P.O. Box 1666 Highland Park, IL john@chinet.chi.il.us (312) 998-5007 (Day voice) || -432-8860 (Answer Mach) && -432-5386 Modem
gandalf@csli.STANFORD.EDU (Juergen Wagner) (01/17/89)
In article <8776@alice.UUCP> debra@alice.UUCP () writes: >Sounds like you have a brain-damaged shell that treats "blackhole" >as a name for /dev/null. Hmmm... I doubt that's the case. If the file were realized as an internal shell alias for /dev/null, you wouldn't get an inode number, and (what's even more interesting), you wouldn't get the same inode number every time. Since the original poster found out the inode number, I guess he has checked that "blackhole" is not just a symbolic link to /dev/null, or another /dev/null with the same device id. Also, the fact that you can re-create it makes the story more suspicipous. I think, one should try a few things: [1] If the file is created on an NFS file system, try the same on the host exporting the file system. [2] Delete "blackhole", create some other files, and re-create your black hole. Does any of the other files have the same black hole behavior? Is "blackhole" still one? [3] Try another shell. If you are running NFS, I suspect an NFS problem. On some occasions (non-reproducible), I noticed that some files appear to have some empty blocks in them (zero bytes), although they seem to be fine on the NFS server. Good luck, -- Juergen Wagner gandalf@csli.stanford.edu wagner@arisia.xerox.com
friedl@vsi.COM (Stephen J. Friedl) (01/17/89)
In article <498@sdrc.UUCP>, scjones@sdrc.UUCP (Larry Jones) writes:
< OK, I've got one for you guys. I've got this file that just
< absorbs whatever get put into it. For example, if I do:
<
< ls -l >blackhole ; cat blackhole
<
< I get nothing.
Uh, Larry, April is not for another couple of months.
My guess is that you just couldn't wait...
Steve :-)
P.S. - what about the *gals* on the net? ;-)
--
Stephen J. Friedl 3B2-kind-of-guy friedl@vsi.com
V-Systems, Inc. I speak for you only attmail!vsi!friedl
Santa Ana, CA USA +1 714 545 6442 {backbones}!vsi!friedl
---------Nancy Reagan on Hawaiian musicians: "Just say Ho"--------mchinni@ardec.arpa (Michael J. Chinni, SMCAR-CCS-E) (01/18/89)
> ls -l >blackhole ; cat blackhole > I get nothing. ls -l blackhole shows it has a reasonable size, > but even od just shows a few zeros. If I do this with a > different file, it works like you would expect. If I delete > blackhole and try it again, I get the same results (I also get > the same inode for the file, which I suspect is critical). Works as expected (i.e blackhole has output from ls -l) on my systems (1 DEC, 2 Gould, 1 MASSCOMP all running unix). /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Michael J. Chinni US Army Armament Research, Development, and Engineering Center User to skeleton sitting at cobweb () Picatinny Arsenal, New Jersey and dust covered terminal and desk () ARPA: mchinni@ardec.arpa "System been down long?" () UUCP: ...!uunet!ardec.arpa!mchinni /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/19/89)
In article <1019@vsi.COM> friedl@vsi.COM (Stephen J. Friedl) writes: >P.S. - what about the *gals* on the net? ;-) Can we stop it with this "sexist language" shit? "Guys" is generic except when specifically contrasted to "gals" or "dolls", which wasn't being done here. I sometimes refer to females here as "you guys" and I've heard females do the same.
friedl@vsi.COM (Stephen J. Friedl) (01/19/89)
In article <1019@vsi.COM> friedl@vsi.COM (Stephen J. Friedl) writes: >P.S. - what about the *gals* on the net? ;-) In article <9429@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: > Can we stop it with this "sexist language" shit? > "Guys" is generic except when specifically contrasted to "gals" > or "dolls", which wasn't being done here. I sometimes refer to > females here as "you guys" and I've heard females do the same. Excuse me for not making the smiley large enough. I'm the last guy on the net (well, maybe second to last behind you) to seriously be concerned about boy-vs-girl references in common speech. The entire posting was in a light tone making fun of Larry: lighten up a bit, Doug. Steve -- Stephen J. Friedl 3B2-kind-of-guy friedl@vsi.com V-Systems, Inc. I speak for you only attmail!vsi!friedl Santa Ana, CA USA +1 714 545 6442 {backbones}!vsi!friedl ---------Nancy Reagan on Hawaiian musicians: "Just say Ho"--------
rikki@macom1.UUCP (Guru's Inc.) (01/20/89)
It's not too surprising that you get the same inode if your system is not too busy. When you delete an inode, he's going to be at the top of the list and ends up being the next one allocated when you make the new file. Any other messages come out? You don't happen to have a space between "black" and "hole" do you? I, too, would like to see the complete output from ls and od.