| Related story time: At university, we ran a local quakeworld server (yes, this was in the stone age XD). And I wanted to write a tool to allow users to control to server. It would listen on a network port and pipe its input into the quakeworld server running as a child subprocess. Sounds simple enough, right? Disregarding accept(2)ing connections,etc... it's just going to sit in an endless loop, select(2) on the sockets then read what comes in, and write that to the quakeworld server. To debug this, everytime someone sent some data over the network, it would write a simple message ("blah") into a file on my home drive, called "~/blah" (very sophisticated debugging, I know). Now, the semantics of select(2), cousin of poll(2), are interesting. My understanding: select(2) blocks until you can read data from the socket. Actual behaviour: select(2) blocks until a subsequent read on the socket does not block. Fun fact: if there's not data available on the socket, read does not block, but returns with an error immediatly. Result: Over the weekend, the process was spinning in an endless loop, writing 'blah' into a file on the nfs-home drive as quickly as the filesystem allowed. This being a university scale solaris NFS server, that's pretty fast. End Result: A test file called 'blah', filled with about 800 GB of 'blah'. Good thing the admins where nice people and didn't shoot me when I went to explain the next monday why the home drive was filled with "blah" XD EDIT: read(2) doesn't actually error on EOF, just returns 0, effect is the same though. |
They should be the ones explaining why they don't have disk quotas set up on a shared system.