I've often run into cases like this where the developers insist on some ridiculous behavior and will not budge and even get angry if you question their decision. Another good example I found recently was with makepkg, a tool for creating packages for the pacman package system on ArchLinux. makepkg refuses to run as root. It used to have an option --asroot which would override this behavior but the devs decided to remove the option in recent versions. They insist that there is absolutely no reason that you would ever need to run makepkg as root and it is just too dangerous for you to be allowed to do so. This makes it extremely difficult to run makepkg inside a Docker container. They say you can just sudo to the nobody user but in Docker this takes many nontrivial steps.
Another good example is Bitcoin where the "core" devs currently have a strangle hold on the community. They've repeatedly made decisions that many disagree with. Now the community has split into warring factions yet still "core" retains its power.
Sure you can fork an Open-Source project but the power is held by those who control the most popular outlet for that software.
Whereas a typical open-source project can, in theory, be forked with absolutely no consequences for those who remain on the original fork. Any change introduced in bitcoin harms those who disagree with it. The analogue by other software would need to be auto-updated software that couldn't be blocked.
Edit: another difference is that if you fork bitcoin and mess up, it can be unrecoverable. It might crash, or all funds might become unspendable, or a couple of other things. If it shakes confidence, then you might not be able to go back.
Also, you can't fully test bitcoin releases in advance because they interact with the network, especially for forks. So you might not know something's wrong until it's too late.
While a mistake in other software can just be reverted, and can be tested independently, because instances are localized.
(Disclaimer: I am simplifying a bit here.)
I agree that the opinion you layout above is probably what the majority of Bitcoiners believe but I don't think it's right. A diversity of code would improve the Bitcoin ecosystem and distribute the control which is currently centralized on the "Core" devs.
Unlike regular software, where different forks can be completely independent.
I don't see what I said that you're disagreeing with.
Windows executables are identified by their extension. That's in direct conflict with POSIX-style executables. You wouldn't want to have to execute every command-line tool like ls.exe, cp.exe, bash.exe, rm.exe etc. So Cygwin looks on the filesystem twice: both with and without the exe extension.
Similar things need to happen when building code from tarballs. It's not just finding executables to actually execute; compilers and linkers need to work correctly too, and random build scripts aren't going to always be checking for the .exe version of files. So the behaviour applies to reading and writing as well.
Tar is already surprising in that it overwrites by default, potentially including the archive you're extracting from. It's usually a bad idea to extract tar archives into anything other than empty directories, unless you know exactly what you're doing.
In fact the dev and other users continue to discuss the reasoning for this behavior for quite a lengthy email chain.
Always assume the best of someone until proven otherwise, it saves a lot of stress :)
MinGW's compilation environment doesn't try to provide a POSIX layer-- if you build something with MinGW, you get a native Windows executable that runs exclusively against the APIs provided by Windows (it's a replacement for the MSVC toolchain).
The MinGW/MSYS/MSYS2 toolchain itself, though (including gcc, binutils, and the shell and coreutils that it's usually installed with), requires a POSIX environment. They got this by forking Cygwin-- which explains why you see the same behavior between Cygwin's tar and MSYS's tar. They share the same behavior because they share code. (The old MSYS was a pretty old fork of Cygwin that they didn't keep up-to-date with upstream, but MSYS2 tries to stay pretty close to upstream Cygwin when they can.)
> tar -xvzf test.tar.gz
> ls myddir
"if the order of the files in
the tar archive is reversed, both files are unpacked. Or, unpack
mydir/myexe.exe explicitely afterwards. The reason that this works is
that Cygwin does not check for a file "foo", if the name of the file is
explicitely given as "foo.exe"."
Also, it's relatively (as in since some years) recent change: "Cygwin always handled the .exe suffix transparently in terms of stat(2)
calls, but Cygwin 1.7 also handles them transparently in terms of
open(2) and any other call."
I haven't fully analyzed the screenshots, I've read just your text, seen the arrow in the screenshot and that way have seen that the files are missing, and only then read the linked explanation from Corina, and that explanation is much clearer: touch or not touch as such is not relevant, only the order of the files in the resulting tar matters, and now it seems to me that your screenshots confirm that: it's just about order during untaring. Thanks.
But it also seems that touch asks "does test exist" and when answered yes it doesn't create it, just changes the datetime. Which probably changes the datetime of test.exe?
Anyway it would be good to investigate which actual calls by the user applications are being made in each case, to know what the actual sequence in each case is.
Didn't read TFA, was just breezing through, and thought I'd see if I the gust of it.
For example, you need to be able to execute a file named "/bin/sh" -- but for that file to be executable under Windows, it needs to be named "sh.exe". If you have a file with no extension in its name, Windows more or less doesn't know what to do with it.
Cygwin's solution to this is to treat "sh" and "sh.exe" as the same file, by tweaking the filesystem code. If "foo.exe" is the only file in the current directory, "ls" will show it -- but "ls foo" will show the same file, but with the name "foo".
Making any system call or library function that searches $PATH for executable files, or that executes a file, accept "foo.exe" when you specify "foo", would have been another solution, and perhaps a better one (though there could easily be some nasty gotchas that I haven't thought about).
There is, as far as I know, no way to implement a POSIX layer on top of windows without some kind of ugly hack for "*.exe" files (short of running a self-contained VM, but the point of Cygwin is that you can still access the Windows filesystem).
You might want Cygwin for some reasons, but for me that would not be those you gave compared to a VM (disclaimer, I use both, at least when Cygwin is working...)
- You want an actually functional ssh server running on windows so you can integrate with a mostly-linux test automation environment.
- You're committed to a (terrible) windows-only VCS, but develop some linux applications.
There's a lot of hoops one would have to get around for a seamless experience with a VM. Most of the time Cygwin just works.
I tried running my Emacs and terminal in a separate VM, wasn't so pleasant. Sharing the file system bidirectionally is the biggest problem.
 I'm sure for certain domains, say unix'y systems programming it's not true at all.
I use it exclusively for CLI stuff via Mintty (the default terminal emulator). The installation just extracts the basic files and lets you download packages. Yes, setup.exe as a package manager is clunky. There's a third party thing called "cyg-apt" it's not that great but works. Personally I just went ahead and downloaded all available packages (just excluded a bunch that were a few GB large).
My 100 most used command: https://gist.github.com/auganov/1242885dbd452db05a47
Currently my only use case is that it does count in my book as a different variety of nix. If you are attempting to have a portable software it is another platform you can use to for testing that can be brought into a CI pipeline.
A more common use case (though still strange) is people using windows natively, who want to use C, C++, Fortran, Ada, etc to make windows programs (instead of cross compiling from Linux). Generally this category is students, and this is still far more educationally beneficial than attempting to learn skills with long term value from say visual studio's IDE.
edit note: asterisks make things italics on hn
A lot of rules. The first rule being to expect exceptions for every rules.
If a natural language can work this way, why not software industry?
Oh! I forgot uncertainties are bad and you may want to get things done in a way that is expected in a way every one understand without equivocation.
Are not inconsistent behaviour defeating the purpose of abstractions? It is an exception to a well expected result.
Cygwin is supposed to be having a low level consistent behaviour. At least that is what POSIX and unix are all about.
I don't see anything good coming from Cygwin and mingwin discarding this critic by a brush of pragmatism.
This leads to odd behaviors, which is unfortunate, but alternatives would lead to even more and/or worse ones.
If a natural language can work this way, why not software industry?"
Huh? They do both work the same way in that respect. Do you wish they did, or didn't?