6 ms·

Symlinks in Windows 10

48 points by KindDragon 10y ago

X-Istence 10y ago
Can we get file deletion in windows without raising an error because the file happens to be opened by some program?
- stebalien 10y 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...).
  - kevingadd 10y 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.
    - aindhaden 10y ago
      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).
  - tcbawo 10y ago
    Perhaps a Copy On Write scheme could work?
  - yread 10y ago
    It's pretty useful for lightweight inter process synchronization
  - captainmuon 10y 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.
  - rleigh 10y 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.
- tonto 10y ago
  there are myriad other reasons files won't delete on Windows that are super annoying ("system file"? Etc)
- PeCaN 10y 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.
- andromeduck 10y ago
  A convenient just kill it button would also work imo.
- jungletek 10y ago
  http://www.emptyloop.com/unlocker/ http://www.emptyloop.com/unlocker/
  - NTripleOne 10y ago
    Site triggers a malware warning in chrome, just a heads up.
IvyMike 10y ago
Discussed three days ago, here: https://news.ycombinator.com/item?id=13092944 https://news.ycombinator.com/item?id=13092944
martin1b 10y 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.aspx https://technet.microsoft.com/en-us/sysinternals/bb896768.as...
- aseipp 10y 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.

48 points by KindDragon 10y ago

X-Istence 10y ago

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

stebalien 10y 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...).
- kevingadd 10y 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.
  - aindhaden 10y ago
    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).
- tcbawo 10y ago
  Perhaps a Copy On Write scheme could work?
- yread 10y ago
  It's pretty useful for lightweight inter process synchronization
- captainmuon 10y 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.
- rleigh 10y 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.
tonto 10y ago
there are myriad other reasons files won't delete on Windows that are super annoying ("system file"? Etc)
PeCaN 10y 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.
andromeduck 10y ago
A convenient just kill it button would also work imo.
jungletek 10y ago
http://www.emptyloop.com/unlocker/ http://www.emptyloop.com/unlocker/
- NTripleOne 10y ago
  Site triggers a malware warning in chrome, just a heads up.

IvyMike 10y ago

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

martin1b 10y 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.aspx https://technet.microsoft.com/en-us/sysinternals/bb896768.as...

aseipp 10y 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.