Cueball is trying to remove the trash bag from his garbage can. However, the trash refuses to let him do so, citing that a paper towel in the trash is being used by some object in his home.
By itself, the comic is patently ridiculous; it is meant as a reflection of a common problem in computer use, specifically that of deleting currently-open files. One cannot delete a file in Windows while it's being used by a program, and Windows will also not tell the user which program it is. There exists programs for Windows, such as Microsoft Sysinternals freeware, which identify which process(es) have a handle open to the file, and even allow force-closing the file, but as this is not shipped as a simple Windows command, most home users are unaware that Windows supports this functionality. https://docs.microsoft.com/en-us/sysinternals/downloads/handle
The title text may be a reference to a simple solution to these sorts of problems: Wait a while, perhaps overnight, and see if the (unknown) application(s) close the open file(s). Alternatively, the user can shut down the system to make absolutely sure that nothing is using anything, and then remove the storage device. In some situations, this is the only way (at least in Windows) to safely remove an external hard drive from a computer.
Also, the title text may refer to the typical "solution" to the file deletion issue: waiting it out. Sometimes, while trying to delete the file, it could get so frustrating that many give up until the next day, hoping it'll fix itself.
This comic draws parallels between the act of emptying a physical rubbish bin and performing garbage collection on a filesystem, iconically represented by Microsoft as the emptying of a virtual wastebin on the desktop. It also may refer the growing trend of Internet of things, which is a concept that enables everyday objects to collect and exchange data. Sometimes when attempting to delete files the software may still have the file marked as in use, because the file is still marked as open by at least one process. The software will therefore prevent its deletion. This may be correct behaviour, as in when a document is still being worked on in a program, or it may happen erroneously, perhaps because the program has not closed the file properly, maybe because of incorrect behaviour. The user is then required to find the cause of the problem and rectify it before the file can be deleted. This may be difficult if the user is not familiar with the file in question, or the program that would have used it.
In the case of the physical bin, the absurdity of this is highlighted by imagining that a paper towel is still locked as "in use" and that the rubbish bin won't allow it to be taken out for final disposal until the household object that was "using" the towel has been identified.
Just for all writers: The Garbage collection prominently belongs to Java. Microsoft had adopted this only in C# and it's NOT used in file systems.--Dgbrt (talk) 14:47, 11 September 2017 (UTC) EDIT by --Dgbrt (talk) 20:47, 11 September 2017 (UTC)
- Note: Java adopted garbage collection over 30 years after it had been used in Lisp. I would question the use of 'prominently belongs'. Any user of Gnu Emacs will be aware of what happens when garbage collection hits unexpectedly... 220.127.116.11 16:13, 11 September 2017 (UTC)
- I have to admit that my first comment doesn't belong to the content of this comic. But, even when you are right (Garbage collection was invented by John McCarthy around 1959 to simplify manual memory management in Lisp.), who really uses Lisp compared to Java? So when trying to explain the GC I would use the most common language using this feature and compare it to the vast majority of other common languages like C, Delphi/Pascal, or scripting languages like Perl or PHP. And we can lisp, sorry list, many more languages in this latter context. In the middle there are object-oriented programming languages without GC like C++, a destructor must be explicitly called which than removes everything belonging to a particular instance on an object. --Dgbrt (talk) 20:47, 11 September 2017 (UTC)
Seams like a pretty clear reference to not being able to empty the computers Trash because files are in use. Normally files in the Trash can't be opened, and files can't be moved to the Trash if opened but weird things can happen. The real rub here is that the computer does know exactly what process has each file open and is intentionally designed and told not to tell you the user the remedy that it already knows nor to show an option to remedy the problem itself leaving you in the lurch. 18.104.22.168 15:37, 11 September 2017 (UTC)
It could be that another user is the one that used the paper towel last. I was actually running into an issue where I couldn't delete a file from a network share that I had used last. The dialog would tell me what program was still using it (Source Tree, which had unceremoniously crashed and didn't close out properly) but my coworker simply got the "Is in use by another program" message. Bpendragon (talk) 15:43, 11 September 2017 (UTC)
I've also come across the issue where the process using the file is the file manager utility itself; I opened the trash to see what was in there, it started trying to make preview images of all the items, and of course when you close the window it doesn't release whatever filehandle it was currently trying to make a preview for. -- Angel (talk) 16:12, 11 September 2017 (UTC)
You could always power the house down and restart it! 22.214.171.124 16:37, 11 September 2017 (UTC)
Part of the joke is how unhelpful windows tend(ed/s) to be in helping you identify the application that is still hanging onto the file.--Henke37 (talk) 17:08, 11 September 2017 (UTC)
This is problem only on MS Windows, where most file-access is blocking; Linux allows deleting file even if some process is accessing it - said process would see old version of the file, while all other would see it deleted. This has its own problems (you delete files, but you don't recover free space), but I think it is less annoying. --JakubNarebski (talk) 18:03, 11 September 2017 (UTC)
- More specific, Windows tracks open files through their pathname, linux tracks open files through their numeric ID. This means that you could create file A, open it, delete the file, create another file B with the same filename, open it, delete the file, create another file C with the same filename, open it, delete the file. Those three files would still be present on the disk, each of the apps that has the file open would see different contents (which they could write to and change), but you would never see any of the files through a directory listing (but it would take up disk space until the files were closed). I believe linux viruses delete themselves to make them more difficult to discover, this also explains why linux system updates don't require rebooting the computer afterwards (although if you just changed the system kernel it's likely recommended)Odysseus654 (talk) 18:26, 11 September 2017 (UTC)
- Note that the numeric ID is called inode - and yes, it's better behaviour for updating. Regarding viruses, well they may do it but it would be bad strategy, as it would remove them on reboot and make them still visible in commands as lsof. -- Hkmaly (talk) 23:49, 11 September 2017 (UTC)
No one though about Docker? That was lit(t)erally my first thought: He must be talking about Docker. Ever tried to find out which container is still using a volume? --AndreKR (talk) 18:30, 11 September 2017 (UTC)
I figured this was about program removal (i.e. "uninstall"). Sometimes one file is still in use (sometimes the program's folder instead of a file), but the rest are deleted as expected. -- BigMal // 126.96.36.199 18:58, 11 September 2017 (UTC)
"...However, the operating system gives no indication of which application(s) have open file(s)..." Which operating systems do this? (Xubuntu tells you which application(s) are the culprit(s). I gather Windows doesn't. OS/X? Other Linuxes? Maybe just say "some operating systems give"? Bill Gray1 (talk) 19:41, 11 September 2017 (UTC)
This is one of the most annoying things windows does, and a huge contribution to why I use macOS and hate Windows! It seems that just about every time I try to do anything significant on windows, I run into this or a similarly frustrating inane problem I never have with a Mac! The one I hate most is when I can't delete an empty folder because either it or a hidden thumbs.db in it is "in use" by the exact same app (windows explorer) as I'm trying to use to delete it! That this is still a problem with a commercially successful OS made in the 21st century is unbelievable to me! PotatoGod (talk) 22:09, 11 September 2017 (UTC)
- Agreed, one of the worst features on windowsDontknow (talk) 23:39, 11 September 2017 (UTC)
I removed the irrelevant commentary that Windows doesn't use the Unix inode data structures, as the object manager provides the functionality allowing file locks to be made, queried, and released. http://m.windowsitpro.com/systems-management/inside-nts-object-manager
Windows also support asynchronous deletion or moving of in-use files.
[Comet] 23:01, 11 September 2017 (UTC)
This is NOT a Windows-only-problem. The very same happens if you try to u(n)mount a partition in Linux. It will fail if a program still has a file on this filesystem open, but Linux does NOT tell you which file is open – you have to use other programs like lsof to find out. --DaB. (talk) 23:28, 11 September 2017 (UTC)
- Asynchronous deletion is nowhere near as useful as the ability to just remove the file and keep just the inode open. But you are right that while Linux doesn't have this problem with files, it does have them with filesystems (partitions) and it can be very annoying. -- Hkmaly (talk) 23:49, 11 September 2017 (UTC)
- Linux will not tell you when using the command line (and you'll have to run lsof), but any modern distro will tell you when using the GUI. Specifically, on Ubuntu 16.04LTS you'll get a window telling you which applications are using the filesystem and will also give you the option to force unmount anyway (at your own risk). -- 188.8.131.52 18:53, 12 September 2017 (UTC)
The thing is, the use of a garbage can here makes for an obvious parallel to emptying the Recycling Bin of Windows ("Trash Bin" before the last decade or so, before Microsoft decided to suck up to environmentalists), except this problem can't appear like that. Programs can't use files or folders in the Bin, they'd have to be restored first. So you can't be blocked from emptying the virtual Bin like this. I can think of two ways to get such an error: Trying to delete a file / SEND it to the Recycling Bin, or trying to disconnect an external drive. Either you can't dispose of a file because it's in use (a file being in the Bin counts as already disposed of), or you can't disconnect the drive the file is on because it's in use. I suspect the same can be said of other operating systems that have a Trash or Recycling Bin (I believe this is indeed true of Macs, that you can't use files in the Trash). NiceGuy1 (talk) 04:43, 12 September 2017 (UTC)
This reminds me more of when I try to eject an external drive (memory stick, portable hd, whatever). If Windows has a file open on it, you can't eject it, and you have to guess what is keeping it locked. --Lou Crazy (talk) 16:39, 12 September 2017 (UTC)
- Me too, I noted that similarity in the edits I just made 😊 It's pretty much the same on Linux and Mac, though those two usually at least tell you which program is blocking the unmount. Usually. 184.108.40.206 08:46, 13 September 2017 (UTC)
Holy crap, this read as an uneducated user Windows hate piece (until I changed it). Resource Monitor has been available since Vista (which is why the SysInternals utility is no longer being developed), and Windows 7 and up has a link straight from the Task Manager. It's also not a Windows exclusive problem. Windows trash bin behaviour is to lock it off from the rest of the system, and is always located on the same drive so "delete" (really a move/rename command) operations are virtually instant; you'd have to be trying REALLY hard to get a locked error from a "send to recycle" bin command, mitigated if the OS/app simply retried a second later.
Here's a FreeBSD link for the same problem: https://lists.freebsd.org/pipermail/freebsd-questions/2012-June/241627.html , for example
For those needing / wanting to educate themselves with file locking and the problems all OSes have, go here: https://en.wikipedia.org/wiki/File_locking --Someone asdf (talk) 16:40, 12 September 2017 (UTC)
- The comic is about emptying the Recycle Bin, not putting things in it. And, no, the Recycle Bin is not on a single drive, as that would be stupid, requiring an actual move operation instead of a rename.
- Resource Monitor is not really all that useful in this situation, as it tells you reads and writes, not which one has files open, and doesn't even tell you where. I'm honestly not sure why it's being mentioned at all. Trlkly (talk) 07:33, 14 September 2017 (UTC)
I just made a bunch of edits to hopefully clean up the article. Hope they were helpful! 🖖 220.127.116.11 08:46, 13 September 2017 (UTC)
- Thanks for your help, the major edits before were done by me but I'm not native English. I disagree that a power down is always safe, either because the user can press the power button for a longer time to force a hard shutdown or when a software triggered shutdown is not able to kill all processes safely. But that's only minor. --Dgbrt (talk) 13:06, 13 September 2017 (UTC)
Not sure what further elaboration is needed, the current explanation thoroughly covers the comic. If others agree can someone mark this as complete now? 18.104.22.168 12:34, 13 September 2017 (UTC)
- I've removed the incomplete tag. If something is missing everybody can add it again. --Dgbrt (talk) 13:06, 13 September 2017 (UTC)
I feel like this comic may also be a reference to the escalation of the "Internet of Things" meme. Take Juicero, an example that was recently in the news, which should be a simple juice press that squeezes juice out of a bag; but the device has a QR code scanner built in, requires a wifi connnection to have the code on the bag verified, and if the code is rejected it will refuse to press the juice. I think the comic works as a satirical take on these type of devices. 22.214.171.124 10:58, 14 September 2017 (UTC)
I am fairly sure that this feature was introduced before the Lisa. I think it originated with the Xerox Alto, or some other system at Xerox PARC. The Lisa might have been the first commercially available system to implement the garbage can. Know your icons: a brief history of computer icons. 126.96.36.199 05:18, 15 September 2017 (UTC)
Title text makes reference to "Objects". This comic is a clear reference to "Garbage Collection" in an OOP language, and not to windows' "Recycle bin".188.8.131.52 04:35, 19 September 2017 (UTC)
A hack for Шindows
I was often annoyed to be unable to delete a whole folder of stuff i do not need, because of 1 file the whole operation would be aborted via spitting out "object is still used" error I installed "Unlocker 1.9.2" app.
P.S. I know it's almost 20's now so it's almost a non-issue, but i am just not from English-speaking country and out of wealth
184.108.40.206 11:10, 22 October 2019 (UTC)
I had interpreted the comic as a reference either to ejecting flash drives and/or to having to force-quit an application when you're trying to shut down the computer 220.127.116.11 15:57, 17 March 2020 (UTC)
- The mention of a trash can/recycle bin is super direct so it is definitivly not that. Though, as stated by others, file in use problems can block just about any operation except killing the process in question. Note, attempting to kill the process may also be blocked because other processes depend on virtual files it provides (happens escpecialy often for processes that mount images). It is also possible for two processes to depend on files provided by each-other, making normal safe kill operations impossible.... in that case your safest option is usually to look at the processes and see if you can convince one of them to let go, (via a dismount, close file, or other buttons/subcommands)