5 ms·

Tl;dr if you have two files in a tar archive, one with an .exe extension and another without, but otherwise with the same name, e.g. test and test.exe, then bot

Tl;dr if you have two files in a tar archive, one with an .exe extension and another without, but otherwise with the same name, e.g. test and test.exe, then both cygwin and msys2 tar will overwrite one of the files with the other on extraction. The developers insist that this is the correct behavior, refuse to even consider changing it and will barely even discuss it. 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.

ikeboy 11y ago
Bitcoin is not a good example, because there can't be competing forks on the protocol level. Once one fork "wins", the other automatically dies. Therefore, it's much more important to get the right design, because individuals in the minority who don't like the choice made by the others have no way to change anything. 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.)
- jcoffland 11y ago
  More than one fork of Bitcoin can and should coexist. There's no reason why miners couldn't run different codes. The worst that can happen is that some blocks are not accepted by the majority and those miners loose the reward. This is perfectly ok and will only push the competing softwares (and miners) to some sort of consensus. 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.
  - ikeboy 11y ago
    They can't coexist for any length of time. That's all I was saying. Unlike regular software, where different forks can be completely independent. I don't see what I said that you're disagreeing with.
zokier 11y ago
I hate that sense of entitlement. The whole point of foss is that people can mold software to fit their vision of how stuff should work without caring about what anyone else thinks. More pointedly the point of free software specifically is to guarantee the power to end users to control the software.
- dave2000 11y ago
  You hate the sense of entitlement that people have when they write software to behave how they want it to behave? Yes, that's shocking.
  - zokier 11y ago
    I'm sorry, I might have been unclear. I meant the entitlement that OP was exhibiting by wanting developers to write software that aligns with his view on how it should work instead of theirs.
ohm 11y ago
Just yesterday I ran into a problem where xfce file manager thunar would show a warning message about using it as root. Every single discussion thread about this issue was closed with a comment how thunar should not be used as root and there will be no feature changes to disable this message.
- TazeTSchnitzel 11y ago
  If it refused to work at all, that would be annoying, but why is it such a problem to have a warning message?
interurban 11y ago
Unless the dev's statement (quoted in TFA) is a blatant lie, this _has_ been discussed multiple times in the past. He also doesn't refuse to discuss the issue, but recommends reading the past discussions before arguing over previously resolved points. 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 :)
barrkel 11y ago
It's not ridiculous behaviour; it's the correct behaviour for Cygwin in almost all cases. 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.
- jcoffland 11y ago
  You are missing the point of the bug/feature described in the article. Neither me or the OP are arguing that you should have to type cp.exe to run the executable. The tar program should always just extract the files contained in it. Instead it overwrites some of them in some cases. This is perhaps related to calling a program with or with out the .exe extension but is only an unnecessary side-effect.
  - barrkel 11y ago
    I noticed that after I wrote the comment, but I doesn't affect my opinion that this is still the correct behaviour for Cygwin. If anything, there should be Cygwin compatibility code added to tar.

ikeboy 11y ago

Bitcoin is not a good example, because there can't be competing forks on the protocol level. Once one fork "wins", the other automatically dies. Therefore, it's much more important to get the right design, because individuals in the minority who don't like the choice made by the others have no way to change anything. 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.)

jcoffland 11y ago
More than one fork of Bitcoin can and should coexist. There's no reason why miners couldn't run different codes. The worst that can happen is that some blocks are not accepted by the majority and those miners loose the reward. This is perfectly ok and will only push the competing softwares (and miners) to some sort of consensus. 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.
- ikeboy 11y ago
  They can't coexist for any length of time. That's all I was saying. Unlike regular software, where different forks can be completely independent. I don't see what I said that you're disagreeing with.

zokier 11y ago

I hate that sense of entitlement. The whole point of foss is that people can mold software to fit their vision of how stuff should work without caring about what anyone else thinks. More pointedly the point of free software specifically is to guarantee the power to end users to control the software.

dave2000 11y ago
You hate the sense of entitlement that people have when they write software to behave how they want it to behave? Yes, that's shocking.
- zokier 11y ago
  I'm sorry, I might have been unclear. I meant the entitlement that OP was exhibiting by wanting developers to write software that aligns with his view on how it should work instead of theirs.

ohm 11y ago

Just yesterday I ran into a problem where xfce file manager thunar would show a warning message about using it as root. Every single discussion thread about this issue was closed with a comment how thunar should not be used as root and there will be no feature changes to disable this message.

TazeTSchnitzel 11y ago
If it refused to work at all, that would be annoying, but why is it such a problem to have a warning message?

interurban 11y ago

Unless the dev's statement (quoted in TFA) is a blatant lie, this _has_ been discussed multiple times in the past. He also doesn't refuse to discuss the issue, but recommends reading the past discussions before arguing over previously resolved points. 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 :)

barrkel 11y ago

It's not ridiculous behaviour; it's the correct behaviour for Cygwin in almost all cases. 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.

jcoffland 11y ago
You are missing the point of the bug/feature described in the article. Neither me or the OP are arguing that you should have to type cp.exe to run the executable. The tar program should always just extract the files contained in it. Instead it overwrites some of them in some cases. This is perhaps related to calling a program with or with out the .exe extension but is only an unnecessary side-effect.
- barrkel 11y ago
  I noticed that after I wrote the comment, but I doesn't affect my opinion that this is still the correct behaviour for Cygwin. If anything, there should be Cygwin compatibility code added to tar.