views:

1621

answers:

7

I noticed when a file is executed on Windows (.exe or .dll), it is locked and cannot be deleted, moved or modified.

Linux, on the other hand, does not lock executing files and you can delete, move, or modify them.

Why does Windows lock when Linux does not? Is there an advantage to locking?

+3  A: 

I think linux / unix doesn't use the same locking mechanics because they are built from the ground up as a multi-user system - which would expect the possibility of multiple users using the same file, maybe even for different purposes.

Is there an advantage to locking? Well, it could possibly reduce the amount of pointers that the OS would have to manage, but now a days the amount of savings is pretty negligible. The biggest advantage I can think of to locking is this: you save some user-viewable ambiguity. If user a is running a binary file, and user b deletes it, then the actual file has to stick around until user A's process completes. Yet, if User B or any other users look on the file system for it, they won't be able to find it - but it will continue to take up space. Not really a huge concern to me.

I think largely it's more of a question on backwards compatibility with window's file systems.

Eric Tuttleman
"Windows" in this context is the Windows NT line. This was designed as a multi-user successor to single-user Windows 3.11. Compare to Unix, which is the single-user successor to Multics.
MSalters
+42  A: 

Linux has a reference-count mechanism, so you can delete the file while it is executing, and it will continue to exist as long as some process (Which previously opened it) has an open handle for it. The directory entry for the file is removed when you delete it, so it cannot be opened any more, but processes already using this file can still use it. Once all processes using this file terminate, the file is deleted automatically.

Windows does not have this capability, so it is forced to lock the file until all processes executing from it have finished.

I believe that the Linux behavior is preferable. There are probably some deep architectural reasons, but the prime (and simple) reason I find most compelling is that in Windows, you sometimes cannot delete a file, you have no idea why, and all you know is that some process is keeping it in use. In Linux it never happens.

Oren Shemesh
woah - almost word for word what I was about to write before it showed up saying that there were new answers!
Mez
What mechanism does Windows use to count the number of processes that have locked the file :) ?
xtofl
Windows uses "Handles", though the semantics of what a locked file "feels" like is much different.
Eric Tuttleman
Note that you can use a tool like Process Explorer in Windows to see what process is using a file/folder.
J c
A practical reason in favor of the Linux behavior is that you can update the OS and other software on the system while it's running, and never/rarely reboot (you can even switch the running kernel without reboot, it's just difficult enough that it's only called for in uptime-critical applications).
joelhardi
"Windows does not have this capability"... are you sure? The NT kernel is based on refcounting objects with handles and references.
Adam Mitz
While it's possible that Windows may technically *have* the capability in current versions, it still doesn't *use* it - my occasional forays into Windows still (in XP, which is NT-based) get the occasional "you can't delete this file because it's in use" error.
Dave Sherohman
+12  A: 

As far as I know, linux does lock executables when they're running -- however, it locks the inode. This means that you can delete the "file" but the inode is still on the filesystem, untouched and all you really deleted is a link.

Unix programs use this way of thinking about the filesystem all the time, create a temporary file, open it, delete the name. Your file still exists but the name is freed up for others to use and no one else can see it.

Neil Williams
"all the time"?Any examples?
Mez
Ask google about "unix secure temporary file" and you'll find enough descriptions of the technique to show that it's well-known and commonly-used. While I don't have any specific examples to give, I dare say any security-conscious app that uses temp files does this.
Dave Sherohman
I wrote a post about this here: http://www.spladug.net/2008/10/temporary-files-in-unix/ Hope this helps
Neil Williams
+6  A: 

There is a utility called WhoLockMe which adds a menu entry to the context menu in the explorer which can display the process(es) locking a given file. Extremely useful when you get weird file-locking errors.

Edit: I know that this is does not answer the question, but I thought it was useful enough in the context to warrant a separate answer (as oppposed to just a comment).

JesperE
This doesnt answer the question that was asked...
Mez
/shrug/ Useful to know.
Bernard
+1 I've been using a port of handle for years
Greg Dean
A: 

NT variants have the

openfiles

command, which will show which processes have handles on which files. It does, however, require enabling the system global flag 'maintain objects list'

openfiles /local /?

tells you how to do this, and also that a performance penalty is incurred by doing so.

spender
+3  A: 

I think you're too absolute about Windows. Normally, it doesn't allocate swap space for the code part of an executable. Instead, it keeps a lock on the excutable & DLLs. If discarded code pages are needed again, they're simply reloaded. But with /SWAPRUN, these pages are kept in swap. This is used for executables on CD or network drives. Hence, windows doesn't need to lock these files.

For .NET, look at Shadow Copy.

MSalters
+4  A: 

Linux does lock the files. If you try to overwrite a file that's executing you will get "ETXTBUSY" (Text file busy). You can however remove the file, and the kernel will delete the file when the last reference to it is removed. (If the machine wasn't cleanly shutdown, these files are the cause of the "Deleted inode had zero d-time" messages when the filesystem is checked, they weren't fully deleted, because a running process had a reference to them, and now they are.)

This has some major advantages, you can upgrade a process thats running, by deleting the executable, replacing it, then restarting the process. Even init can be upgraded like this, replace the executable, and send it a signal, and it'll re-exec() itself, without requiring a reboot. (THis is normally done automatically by your package management system as part of it's upgrade)

Under windows, replacing a file that's in use appears to be a major hassle, generally requiring a reboot to make sure no processes are running.

There can be some problems, such as if you have an extremely large logfile, and you remove it, but forget to tell the process that was logging to that file to reopen the file, it'll hold the reference, and you'll wonder why your disk didn't suddenly get a lot more free space.

You can also use this trick under linux for temporary files. open the file, delete it, then continue to use the file. When your process exits (for no matter what reason -- even power failure), the file will be deleted.

Programs like lsof and fuser (or just poking around in /proc//fd) can show you what processes have files open that no longer have a name.