1888: Still in Use

|< < Prev Comic #1888 (September 11, 2017) Next > >|

Still in Use

Title text: 'Which one?' 'I dunno, it's your house. Just check each object.' 'Check it for *what*?' 'Whether it looks like it might have touched a paper towel at some point and then forgotten to let go.' '...' 'You can also Google to learn how to check which things are using which resources.' 'You know, I'll just leave the towel there and try again tomorrow.'

Explanation

Cueball is trying to remove the trash bag from his garbage can. However, the can refuses to let him do so, citing that a paper towel in the trash is being used by some object in his home.

This comic draws parallels between the act of emptying a physical rubbish bin and emptying the recycle bin integrated into a desktop computing environment like Windows, macOS, most Linux derivatives, and others. It originated with the Xerox Alto, but was first commercially introduced on Apple Lisa in 1982 called Wastebasket and, while it was adopted by most other desktop environment operating system, using slightly different names, the main purpose still remains: A user can restore a file after they have deleted it -- hence the most common name recycle bin, you still can get your paper towel and use it again. In many (earlier) command line based systems like DOS or UNIX/Linux (besides the desktop interfaces) a removed file was gone. Some undelete commands exist, but there are hard restrictions because the then free space on the hard drive must not have been used again and often file names aren't fully recoverable.

But sometimes when attempting to delete files, a running program may still have the file marked as in use. The operating system will therefore prevent the file's deletion, but some do not tell the user which program is using the file.

Preventing the file from being deleted from the file system in this case may be a correct behavior, because the document is still being worked on. But sometimes it may happen erroneously, perhaps because of a program not closing the file properly, a glitch in the operating system, or user error. The user then is required to find the cause of the problem and rectify it before the file can be deleted. This may be difficult because error messages may not reveal the affected file or the program blocking its removal. Similar problems may occur when unmounting (or "safely removing") a removable storage device.

The title text may refer to a simple solution to these sorts of problems: Wait a while, perhaps overnight, and see if the (unknown) application(s) have closed the open file(s). Alternatively, the user can shut down the system to make absolutely sure that nothing is using anything. This is usually effective and harmless -- programs that falsely flagged something in the recycle bin as "in use" usually won't recreate the problem when the computer finishes booting up -- but this is really not a convenient solution for the user because all applications are closed.

Solutions

Advanced users may be inconvenienced by unhelpful error messages but at least are likely to know the tools available to solve the problem. However, a less experienced user just trying to free some space is not only annoyed, their only solution is to reboot or shut down the computer.

Some tools:

• On Windows, the "handle" command line tool allows listing, searching, and closing file handles, showing the associated process.
• On Linux and OS X there is a command line tool lsof (list open files) which also lists open sockets and more. If the filename or program name is known, the usefulness of this tool is vastly enhanced by combining it with grep.
• Unix systems derived from SVR4 have the fuser(1) command (fstat(1) on BSD) that lists and optionally kills the process keeping a file open. It's useful on shutdowns because open files can prevent unmounting filesystems, potentially leaving them a mess.

Transcript

[Cueball is trying to take out a trash bag from his garbage can.]

Trash: Sorry, you can't empty the garbage yet. A paper towel in here is currently in use by some object in your house.

 add a comment! ⋅  add a topic (use sparingly)! ⋅  refresh comments!

Discussion

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... 141.101.98.112 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)

Both Perl and PHP are using garbage collection. So do Python, Ruby and Javascript. -- Hkmaly (talk) 23:49, 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. 172.68.206.58 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! 162.158.78.28 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 // 108.162.216.166 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. https://docs.microsoft.com/en-us/sysinternals/downloads/movefile

[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). -- 162.158.63.28 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. 141.101.104.215 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! 🖖 141.101.104.215 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? 141.101.99.161 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. 108.162.249.22 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. 172.68.132.209 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".108.162.212.161 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

141.101.104.59 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 162.158.79.107 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)

I don't think this is cut and dry definitely about the trash bin, XKCD comics have abstracted elements before for comedic effect. I would settle on mentioning both in the explanation. 172.70.42.88 18:15, 4 May 2023 (UTC)

Coming late to this, though must have seen it before, it is not an unknown occurance to be not allowed to 'delete' an item (i.e. move it to the Recycled Bin/whatever, or indeed full-delete it from scratch) because it is locked by the FS/OS, but things in the bin are purposefully made less easy to use in their new situ (not impossible, but generally escape most application-locks or a 'folder view preview' that undeleted files suffer).

Whereas not 'allowing' (or at least not giving the user permission for) the removal of a USB storage device, from the socket it was inserted into, is very much an analogue of not removing a refuse sack because of some hidden reservation of its contents by some random other association..? That's a thing that happens. With the exception being that the frustrated user can always pull it out anyway, and risk an incomplete-write corruption if it's 'optimised' that way, if they really want to. 172.70.85.169 19:49, 4 May 2023 (UTC)