Ln – NTFS hard/symbolic link command line tool | Hacker News Reader

Ln – NTFS hard/symbolic link command line tool

schinagl.priv.at

59 pointsJonnieCache27 comments

It seems a little unfortunate to have the name clash with the well-known Unix utility (this appears to be intentional? See how the web page is laid out like a traditional Unix manpage, too), but without the same command line arguments as said utility.

If this is important to you (as it is to me), it's worth noting that Cygwin supports creating native NTFS symlinks, and you can use the good old GNU ln (same one you'd use on Linux!) to do so. There are some caveats, but it should at least attempt them. See the documentation: https://cygwin.com/cygwin-ug-net/using.html#pathnames-symlin...

Like I said in another comment, it's the ACL impedance-mismatch that's the problem with cygwin :(

It's a different issue. I sympathize that you can't really back up files with Cygwin and maintain the same file attributes (it's certainly not impossible for them to do it while maintaining a POSIX nature -- FreeBSD and illumos have no issues with NFSv4 ACLs, which are a superset of all the NTFS ones), but as far as making sym- or hard-links to files, Cygwin is perfectly fine.

(And let's not mind that NTFS is complicated enough that almost all native Windows tools won't backup it either. Your best bets are wimlib or dism...)

See also the SysInternals junction utility, which has provided NTFS linking funtionality for years:

https://technet.microsoft.com/en-us/sysinternals/bb896768.as...

Or mklink, which has been available since Vista.

https://technet.microsoft.com/en-us/library/cc753194(v=ws.11...

Support for symlinks in Windows 10, at least, just got better (or rather easier) for those of us on the Insider Fast Ring: https://blogs.windows.com/buildingapps/2016/12/02/symlinks-w...

Replying to self as to not change the actual content of my original post. Since August, I've been using Win10 w/ the Windows Subsystem for Linux almost exclusively for my Linux development instead of ssh'ing into a local VM. I can do 100% of what I need for writing software. I'm primarily a C++/Python developer on linux. My IDE of choice is bash. I use vim as an editor, and gnumake to build, although I use pretty_make.py [1] to format GCC errors a little better and add colorization, etc. I use multiple wide-screen monitors, so screen realestate is not an issue for me (I usually have 2 bash shells split vertically per monitor).

One big downside for me is that I cannot actually run the code I build locally because the codebase I'm working on needs to enumerate & name the network adapters that are present, and WSL doesn't yet (, if ever) support this.

But, for what I'm currently doing, which is code cleanup and goal #1 is just clean compiles w/ no warnings as errors (w/ -Wall -Wextra -pedantic -Wno-zero-as-null-pointer) & links, it's a great productivity saver.

[1] https://github.com/myint/indent-finder/blob/master/test_file...

WSL does support network adapter enumeration as of build 14965.

Take a look at this blog post from November: https://blogs.msdn.microsoft.com/commandline/2016/11/10/ifco...

Have you tried MSYS2 instead of WSL for your use-case?

The standout for me is --delorean which is basically rdiff-backup for windows. There's a wrapper script for it here with some extra options: https://github.com/International-Nepal-Fellowship/Windows-To...

Also this page badly needs a ToC.

rdiff-backup computes reverse diffs between files for multi-generation backup. This looks more like an implementation of rsnapshot, which maintains full copies of old versions of files (rather than reverse diffs). (I run rdiff-backup on Windows and find that it works well.)

Ah I'm confusing it with rsnapshot. I'd assumed they were the same. I'm confusing incremental with differential I guess.

Are you running rdiff-backup in cygwin? How do you find it deals with the ntfs ACLs? I'm looking for a way to do incremental full-disk backups that leave the files on disk in a "natural" state, with their original pathnames/ACLs/ADSs and not in some weird archive format. Although I suppose rdiff doesn't count as "weird" being as its open source and well supported.

TBH I'm quite liking the look of the windows built-in backup function, I like the idea of the shadow copy service and storing disk images as VHLs. Booting into the backups in virtualbox sounds cool.

The problem is that the "Previous Versions" get stored on the primary drive, not the backup drive, eating into my free space. Unfortunately one can't set it to use the empty space, it wants to preallocate. You also can't set a time interval, only a percentage of the volume.

As far as I can tell consecutive VHL images don't get stored as diffs or anything, they're separate, meaning I'd really only get one at a time.

Oh, come back Time Machine, all is forgiven.

I'm running the 1.3.3 Win32 build (http://savannah.nongnu.org/download/rdiff-backup/rdiff-backu...). It is supposed to handle NTFS ACLs but I haven't looked at it in-depth because my, for my application, I don't need ACLs to be preserved.

I wouldn't think rdiff-backup on Win32 is suitable for an OS backup. I'm backing-up a particular application's directories only, so I can get away with using it.

The built-in Windows Backup's image-based backups are reasonable (at least in Windows 7, 8.1, and Server 2008 R2 and 2012/2012 R2-- I haven't tried it with other Windows versions). You get a VHD file (VHDX in Server 2012) that can be mounted, as you say, in Virtualbox, etc. I suppose it would be bootable, but I'd never thought to try that.

"Previous Versions" is a user friendly interface to Volume Shadow Copy (VSS) that takes periodic snapshots of a volume and presents them in a GUI. Data for "Previous Versions" is stored in the volume that's subject to snapshot.

Windows Backup also uses VSS snapshots to maintain multiple versions of the backup. These snapshots are stored on the backup destination, however. I think you may be conflating the "Previous Versions" feature's use of VSS with Windows Backup's use of VSS.

To access the VSS snapshot versions of the VHD(X) file directly that Windows Backup creates it's necessary to expose the shadow copies (using a variety of different methods-- "diskshadow.exe", or "mklink.exe" being the two most common). You can also use the GUI restore interface to restore files from a previous snapshot of the VHD(X) file.

Thanks very much, I spent hours yesterday looking for a specific description of how the VHDs and VSS interacted and couldn't find it. A bit ridiculous really.

Word of warning on those backup systems: occasionally run a full-checksum/file-contents sync in case of corruption.

What's the difference between this and New-HardLink and New-SoftLink, which are part of PSCX? http://pscx.codeplex.com/

Eras, the bane of my existence.

*NIX: Hard links since the 70s. Glad Windows is becoming less of a toy.

NTFS hard links have been available since NT4, released 31 July 1996.

And finally out of beta.

While bsdlove's comment wasn't that great, were not most Windows users not using NT until Win2k, and even then, sym & hard links weren't useful, since you needed (and continue to need¹) administrative privileges to create them?

¹excepting the recent change where a "developer mode" can be activated, but that still doesn't make them useful on an end user's machine, or to an end user.

Developer mode is just a place for MS to stash new beta features so they can be tried out for a longer period of time than Insider Rings are allowed. I'm willing to bet it'll be default in another release or two w/out dev mode.

Hard links and directory junctions (the sort of directory symlinks that existed before Vista) never required administrative privileges.

Well at least with hard links that's not strictly true. Using official win32 apis you need write permission on the file you're linking to so you can't link to say a system file as a non admin. Try mklink with the /H switch.

Of course that's a bit of a lie, if you use the NtSetInformationFile api you don't need write access :-)

To repeat myself: https://news.ycombinator.com/item?id=13095172

> While bsdlove's comment wasn't that great, were not most Windows users not using NT until Win2k, and even then, sym & hard links weren't useful, since you needed (and continue to need¹) administrative privileges to create them?

To be fair it was first with Vista that Microsoft tried to seriously lock users down and keep administrative privileges far away for the common user.

I'm pretty sure most Windows 2000-users had admin rights. This was not the reason symlinks was not adopted.

.. but not with a standard command-line tool shipping with the OS to create them. Which was kind of an odd decision.

Reply on news.ycombinator.com