Path: utzoo!attcan!uunet!lll-winken!ames!haven!purdue!decwrl!labrea!csli!gandalf
From: gandalf@csli.STANFORD.EDU (Juergen Wagner)
Newsgroups: comp.unix.wizards
Subject: Re: Black hole file
Message-ID: <7131@csli.STANFORD.EDU>
Date: 16 Jan 89 21:06:35 GMT
References: <498@sdrc.UUCP> <8776@alice.UUCP>
Reply-To: gandalf@csli.stanford.edu (Juergen Wagner)
Organization: Center for the Study of Language and Information, Stanford U.
Lines: 31

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