2. `mklink` [0] has existed since Windows Vista for NTFS file system. No settings toggling required.
3. What is your argument against PowerShell? In what ways does it fall short? I have been pretty successful with using it for various tasks.
4. This is about the only legit claim. Windows always requires full credentials to execute as another user. Windows does provide `runas.exe`, but you must provide the target user's full credentials.
[0] https://technet.microsoft.com/en-us/library/cc753194%28v=ws....
There are several limitations in the Windows/NTFS implementation, however:
1. You have to specify the target type (file or directory) at link creation time.
2. Creating symbolic links requires either being an Administrator user, or having the "Create symbolic links" group policy enabled for your account.
3. No real directory hard links. (EDIT: For some reason, I forgot that Linux doesn't have these, either. Maybe I was thinking of bind mounts.)
Windows isn't the only OS that disallows creating directory hard links.
http://askubuntu.com/questions/210741/why-are-hard-links-not...
Powershell is an acceptable scripting language. It's a horrible interactive shell. They shoudn't have made "shell" part of its name if they weren't going to at least include basic interactive features like readline compatibility and usable tab completion.
My experience with tab completion in PowerShell is great. It completes file paths, command names, command parameter names, and even command parameter values if they're an enumeration. Could you describe what else you would expect to see?
I would call it something more than acceptable scripting language. It is object oriented and it can easily use C# libraries, which is pretty neat.
b) http://mridgers.github.io/clink/ is bloody fantastic.
NT has a root directory like Unix does. Drive letters are symbolic links inside a directory called \DosDevices.
Granted, this is not user-visible but an implementation detail. The needs of Win32 applications dictate a lot of user-visible behavior.
> 2. Creating symbolic links to files and folders,
NT supports symbolic links. Open cmd and type "mklink".
The shell itself and the rest of userland has very little to do with the kernel. It seems its the userland you are upset with. Swapping out the kernel won't fix that.
You can create hard and soft links. PowerShell is great, just different. UAC is not sudo, but works very well. It's a different OS.
For some values of well. If you logon interactively and start a powershell session, you do not have administrative powers and cannot get them without opening a new shell. If you logon via PS remoting, you have administrative powers by default and cannot lose them.
UAC is a GUI kludge, and is very grating especially in Powershell.
This is probably the number one cause of me banging my head against the desk and wishing Windows behaved more like Linux.
OTOH there are other limits that are not dictated by dwShareMode. Such as deleting files while handles are open - this blocks a new file with the same name from being created until all handles are closed. That's probably the worst one. There are some other crappy ones involving directory handles that I don't care to enumerate.
It's neither. It's a common misconception. See https://news.ycombinator.com/item?id=11415366 .
Windows isn't the only OS having file locking implemented at kernel level.
> 1. The use of drive letters A-Z for file system access.
Indeed it is not. The kernel sees a single root for the object namespace, not drive letters.
3. Userland issue. You can compile bash and an ssh server for Windows if you want. PowerShell is quite different, yes.
4. exists, both in GUI and commandline.
Symbolic links is supported by NTFS, just not exposed to normal users.
That's just your opinion about powershell...
UAT, and runas?
Why is this a problem? As a user, I've always preferred to have drive letters - it makes it immediately clear if, for example, I'm moving files between different physical drives.
