Editing 1888: Still in Use
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.
The edit can be undone.
Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 10: | Line 10: | ||
[[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. | [[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 {{w|Trash (computing)|recycle bin}} integrated into a desktop computing environment like Windows, macOS, most Linux derivatives, and others. It | + | This comic draws parallels between the act of emptying a physical rubbish bin and emptying the {{w|Trash (computing)|recycle bin}} integrated into a desktop computing environment like Windows, macOS, most Linux derivatives, and others. It was first introduced on {{w|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. | 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. | ||
Line 16: | Line 16: | ||
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. | 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. | + | 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. But this latter solution is really not a convenient one because all applications are closed. |
== Solutions == | == Solutions == | ||
Line 22: | Line 22: | ||
Some tools: | Some tools: | ||
− | * On Windows, the [https://docs.microsoft.com/en-us/sysinternals/downloads/ | + | * On Windows Vista and above, one may use the "Task Manager" and the aptly named "Resource Monitor". Nevertheless there is also still the [https://docs.microsoft.com/en-us/sysinternals/downloads/procmon "Process Monitor"] from Sysinternals available at Microsoft. |
− | * On Linux and OS X there is a command line tool {{w|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 {{w|grep}}. | + | * On Linux and OS X there is a command line tool {{w|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 {{w|grep}} because dispensable lines can be omitted. |
* Unix systems derived from SVR4 have the {{w|fuser (Unix)|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. | * Unix systems derived from SVR4 have the {{w|fuser (Unix)|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. | ||