Symlinks in Windows 10
blogs.windows.comDiscussed three days ago, here: https://news.ycombinator.com/item?id=13092944
Can we get file deletion in windows without raising an error because the file happens to be opened by some program?
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...).
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.
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.
I don't see what "regular people" has to do with it... you either know how your filesystem works or you don't. I you don't, the Linux way (I deleted a file but it's still in my editor) can be just as confusing as the Windows way (I can't delete or move or rename this file because it says it's in use, but I don't have any programs open that use it).
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.
It's pretty useful for lightweight inter process synchronization
Perhaps a Copy On Write scheme could work?
A convenient just kill it button would also work imo.
there are myriad other reasons files won't delete on Windows that are super annoying ("system file"? Etc)
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.
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...
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.