Back when I worked at SUARIT at UNC Charlotte (before it was reorganized into SAIT, and later OneIT), we were a fairly tight-knit group. I knew just about all the full-time staff we supported and was on a first-name basis with most of them.
Some of them I knew quite well, because they tended to file a fair amount of tickets. This is not a bad thing, of course – if you’re not good with technology, we would much rather you come to us with your questions than click the first sponsored result in Google that gets you to install ransomware – just an observation that a few users filed a disproportionate number of tickets. This particular story is about one of those regulars, and it occurred during our migration from macOS 10.12 Sierra to 10.13 High Sierra.
For machines assigned to permanent staff members, the upgrade was made available for them in Jamf Self Service to install at their leisure, and all had been progressing well until one day we got an interesting ticket from a user who tried to install the upgrade and failed.
We had dealt with some problems during our testing of High Sierra, but had ironed out all the rough spots (or so we thought). Since everything had been proceeding normally up until now, this immediately caught our attention.
Upon further investigation, we found that the upgrader was refusing to run due to a lack of free space. This really tripped us up, because we had to create scripts for shared machines in common areas to purge users who had not logged in recently to prevent these problems - it had never occurred before on a permanent staff machine.
Our first suspicion was that this machine was shared more than we were led to believe, but a quick check in Jamf revealed there were only a handful of user profiles on it.
So, we dug deeper, and quickly found the source of the problem: the primary user’s Trash was massive. Literally over 200 GB (on a 256 GB SSD), most of them image files.
So we asked her about this, and what she told us blew our minds.
Inside her Trash, there were two folders: Good Trash and Bad Trash.
Every day, when she logged in, she would extract the folders to her Desktop, do her work in the Good Trash folder, and stow them back into the Trash before logging off for the day. (Stuff she actually wanted to get rid of went into the Bad Trash folder.)
Because they were being constantly cycled in and out of the Trash, they never got old enough for the auto-trash emptying (which we enforced via Jamf) to get rid of either folder (well, assuming she never fell ill or otherwise had to take an extended leave of absence).
And why was she doing this? Because, in her words, “you told me not to store stuff on my desktop.”
I think this underscores an important point when it comes to technical communication: always tailor it to your audience and provide specific recommendations.
Previously, this person had lost a lot of files (including most of her work files) because she stored everything on her desktop, and the spinning hard drive in her old iMac died, after which we made it clear that she could not continue storing stuff on there because she was another unfortunate incident away from losing all her work again and forcing the department to shell out for data recovery services.
Technically, Trash is not the Desktop, so she wasn’t literally wrong, but she didn’t really understand that we meant “don’t store anything on the local system.” What we meant was “store your files on the network drive, Dropbox, Google Drive, anything but locally,” but for someone who isn’t tech-savvy, that connection may not be obvious. In fact, it took some explaining to get across the concept of local storage vs. networked storage vs. cloud-synced storage and the redundancies (or lack thereof) of each option.
Ultimately, we got her to save all her non-image stuff to her department’s Google Drive, and got her department to purchase an external drive for all the pictures (which were of department events), so all’s well that ends well, but it was still a valuable lesson in technical communication.