Mounter, automounter, what's the diff
I worked at a large bank where there was a culture clash between the ancient whitebeards who used the ancient, grotty old IBM mainframes, while the younger generation of Sun worshippers (Hail to the Sun god, he is a fun god, Ra Ra Ra) basked in the glory that was Unix. Specifically, SunOS.
One of the major benefits, they explained to the whitebeards, was that, unlike the mainframe, if the network died, individual Unix workstations would keep running. As they were saying this, someone upgraded the SunServer automounter, meaning that the workstations could not mount things from it. At which point, every Sun workstation on the floor also stopped working. In order to save space on the individual workstations, they loaded the /bin directory from the file server. Fortunately, the local workstations also had /usr/local/bin, but in a fit of overly aggressive optimization, that too was loaded from the server.
This led to the bizarre admission that "SparcOS can't run $BUSINESSAPP until it can load /usr/local/bin from the file server", which led to management asking the fair question of why one had to load a "local" object from the remote server.
Mind, it's not always the person deleting the directory who is at fault.
I worked on a shared lab machine in the 1980s where space was tight. I was working on a video project, so I created a directory \DEVTEAMS (this was during the days of DOS 3 and 8.3 file names), and under it, I created VIDPROJ. Another group was doing a transputer project, so I also created TRANSPTR. That way, anyone who backed up the shared machine's \DEVTEAMS directory would back up both projects, \DEVTEAMS\TRANSPTR and \DEVTEAMS\VIDPROJ.
The transputer team had different ideas, though. They used their teams initials. So Charley, Uri, Norman and Kevin put their development work in the directory C:\JUNK.
Well, one day, a team member found that there was only 2kb of disk space on the 10MB (or maybe it was 20MB) drive. So, the first thing he did was run a backup of \DEVTEAMS, and then he went around seeing what he could get rid of to free up space. He found a directory C:\JUNK, and it was filled with thousands of small (10 to 50 byte) files with names like $d217.d78 and $aix7.7$a. They were obviously cache files of some kind, so he wiped them and freed up about 1.5MB of disk space.The machine now had enough space to run his build.
The next day, the head of the transputer group was livid. His team's entire project had been destroyed on the lab machine. There was month's worth of work gone! It turned out that instead of saving source files, the transputer development tool saved their source as hundreds of individual source objects, and maintained a database of how to link them. In other words, hundreds of little files with autogenerated file names, like $d217.d78 and $aix7.7$a
Yes, on a shared machine, they set up a directory called JUNK, and filled it with binary files with names like $3j5a1.d7x, and were upset people looking to clean out dead files didn't realize that those were critical project files.
Although they weren't so critical that their team ever bothered to back them up once in the span of six months, of course.
Biting the hand that feeds IT
