Symlinks in Windows 10

Symlinks in Windows 10(blogs.windows.com)

48 points by KindDragon 9 years ago | 16 comments

IvyMike 9 years ago |

Discussed three days ago, here: https://news.ycombinator.com/item?id=13092944

X-Istence 9 years ago |

Can we get file deletion in windows without raising an error because the file happens to be opened by some program?

stebalien 9 years ago | |

Not without breaking every program under the sun. Currently, programs on Windows can assume that the file associated with a path won't change while the file is open (at least I hope so or some of my code is a bit racy...).

captainmuon 9 years ago | | |

You could make it so that an application holding a file handle will always see this filename existing as long as the file is open. This is similar too, but not quite, what happens under Linux (the filename goes away, but the open file is still accessible as long as one process holds an open handle).

Or, if you wanted to be extra careful, just introduce a new locking flag (LOCK_DONT_LOCK_CAN_DELETE or whatever :-)). Then bug the authors of the most popular editors and the most buggy applications (which block files unneccesarily) to set the flag. If you want to, you could create a compatibility shim to force enable / disable this feature for a given application. (Edit: apparently this flag already exists? FILE_SHARE_DELETE?)

This is tricky, but probably not harder than e.g. modernizing the console subsystem.

kevingadd 9 years ago | | |

Same goes for directories, yeah. The linux approach can create some really bad user experiences and weird bugs. It's sysadmin-friendly but no good for regular people.

rleigh 9 years ago | | |

Not if it's a CIFS mount on a UNIX platform. I'm sure there are other examples. In practice, most software copes just fine with this arrangement.

I suspect that the breakage would be fairly limited, and I for one would love for this to happen. The amount of stuff which can't be done because of this design decision is huge; proper package management without numerous reboots would be one, and I think the benefit of that and having semantics common with Unix platforms would outweigh the breakage.

yread 9 years ago | | |

It's pretty useful for lightweight inter process synchronization

tcbawo 9 years ago | | |

Perhaps a Copy On Write scheme could work?

jungletek 9 years ago | |

http://www.emptyloop.com/unlocker/

NTripleOne 9 years ago | | |

Site triggers a malware warning in chrome, just a heads up.

andromeduck 9 years ago | |

A convenient just kill it button would also work imo.

tonto 9 years ago | |

there are myriad other reasons files won't delete on Windows that are super annoying ("system file"? Etc)

PeCaN 9 years ago | |

That… seems like probably a mistake, partly because of existing programs and also because it's not too clear what the correct behavior is there. Yes it's annoying, but I think it's also probably the least surprising behavior.

martin1b 9 years ago |

Why create a new util when Mark Russinovich already created 'Junction'. Aren't these the same thing? https://technet.microsoft.com/en-us/sysinternals/bb896768.as...

aseipp 9 years ago | |

Junctions and symbolic links are very different things on Windows (NTFS also supports hardlinks, distinctly from these other two. You can think of a junction point as a hardlink, but only for a directories, with some other differences dealing with things like network shares. Ordinary hardlinks/symlinks support files as well as directories, however.)

The `mklink` tool in Windows is also by no means new; it's been around for many years. It just wasn't very useful since you needed to be an admin to use symbolic links, anyway.