Hacker News Reader

Comment by petilon | Hacker News Reader

On Linux if a file can't be edited because some process is holding it open you can just mv the file to /tmp and create a new file in its place. The process that has it open is unaffected because the handle is independent of the path.

On Windows a file that is open in an application cannot be moved, plus it won't tell you which process has it open. Yes you can use some sysinternals tool but this is basic info that should be immediately available without installing some additional tools.

View on HN

> because the handle is independent of the path.

This makes me wonder, what happens [EDIT: on Windows] when a program uses a file, which more than a single hardlink points to, and you want to remove one of them. Does it matter, through which hardlink the file gets opened or are all the hardlinks prevented from being unlinked?

On Linux you can delete all hardlinks to open files.

What you can't do is modify a file that's executing (program or library), then you get ETXTBSY.

My question was about Windows, yeah on Linux it obviously doesn't matter, because you can unlink it even if there is only a single hardlink. My bad, I should have written it.

> What you can't do is modify a file that's executing (program or library), then you get ETXTBSY.

Why can't you? Couldn't it do the same thing and just keep it in memory?

Edit: Actually on my system, I can start a program, unlink it and keep using it just fine. I wonder what case you are referring to.

ETXTBSY isn't even descriped in unlink(2), but it is in unlink(3posix): ETXTBSY - The entry to be unlinked is the last directory entry to a pure procedure (shared text) file that is being executed.

Hard links are just pointers to the file. You can remove any or all of them independently of each other and the running program. In fact, IIRC there's a semi-common pattern where a program will deliberately create a file, open it, and then unlink it, which leaves it usable but anonymous and in a state that will always be garbage-collected when the program exits.

On Windows you can't remove a file while a program is using it, that's the topic of the post. To me that implies that Windows can't keep a file around without having a hardlink to it. But what happens when there is more than one hardlink? Hence my question.

Oh, on Windows. I have no idea:)

Yeah, me neither :-)

At most I use GNU/NT.

I seem to remember that you could, however, rename the file for a similar effect on Windows.

No, you can't rename a file in use, unless it is explicitly opened with a sharing flag (which most applications don't).

I don't know, but that's what the article says Microsoft recommended as a workaround.

In windows the shadow copy facility is used to sneak files around when they are open. I remember using a utility called "hobocopy" (a sort of pun on the more famous robocopy) that provided a command line user interface around shadow copy to let you move locked files.

In my specific case it was to save youtube videos when it was still a flash player. the video would be cached in a file but that file would be inaccessible because it was "open" hobocopy to the rescue. On linux it would make then delete the file depending on the open file descriptor to keep it around. The way to save it was to relink another name onto the inode. I can't quite remember but on linux I think you could use a /proc entry to get that inode and on obsd I would use fstat to find it and fsdb to make the relink.

As a unix aficionado I despise windows open file locking with a passion. Sure I understand it is probably more correct, An open file could be in any sort of corrupted state the only safe thing to do is default to single access and locking. But it is far more respectful to the user to just let them grab it whenever they want to. corruption be dammed.

You can also just unlink it.

Reply on news.ycombinator.com