[win32]<>[linux] X bit gets set on every file if you access a working tree in a win32 filesystem from Linux

[Adrian Wilkins]

If you access a working tree written into a Windows filesystem (FAT32, NTFS) from Linux, Bazaar sets the X-bit flag for every file in the tree. When you revisit the tree in Windows, the X-bit is not dropped from the inventory.

At best, this is a major annoyance as it will generate a spurious change of every file in the tree unless you revert (and then unpick the bits of the revert you didn't mean to do like source changes from their backups).

At worst, this is potentially a security risk as files that are not intended to be +x may get committed and checked out into a Linux working tree.

Not quite sure how to fix it though.

 - An x-bit option for "revert" would make this less onerous, but it wouldn't resolve the underlying problem.
 - An option to ignore x-bit in the filesystem coupled with a means of manually setting x-bit in the inventory would work.

The obvious workaround is that disk space is cheap and doing a checkout into a native *nix file system isn't hard.

[Vernon Cole (vernondcole)]

The "obvious workaround" suggested above does not work -- because this bug "poisons" a windows implementation as well.
I spent the entire morning writing this up as a new bug -- and I am going to include the whole document I created here. Post it near the water cooler -- it's good for a chuckle.
--
Vernon Cole

v v v v v v
 I have to write this up as a bug report, because there is no other way to correctly document it. Will it ever be “fixed?” Probably not. In fact, by the time you get to the end of this document, you may add a new priority for bug fixes – lower than “Low.” Perhaps you should call it “Are You Kidding?”
 There is an old joke about the guy who goes in to his doctor, complaining about a pain when he performs some very unnatural action. The doctor's advice is: “well, don't DO that!”
 But then the doctor just HAS to ask what brought about the situation, and the story comes out. This is like that. I can't help myself. I am an eccentric geek. We do this sort of thing. I also wrote a Python class implementing PEP 313 (also known as PEP CCCXIII) and published it on Launchpad. I can't help myself, it just HAPPENS!
 In reality, this is praise – not a complaint. If it were not for the countless hours spent by dedicated FOSS software engineers, I would never have been able to get into this situation. My situation is a result of the resounding success you have achieved in creating cross-platform software. Well done!
 So before you read on, get up, take a break, go to the rest room, and get a fresh Coke on the way back to your desk. Then proceed.
- - - - - - - - - - - - - - - - - - - - -

The situation and the guilty parties and components:...

Me:
  I first started going crazy when employed by John Fluke (the company) in Washington state. John Fluke (Junior -- the person) had the idea that Test Engineers would be more efficient if they had a better language in which to express their design of programs for Automatic Test Equipment. A young electrical engineer came up with the idea of a table of test steps and responses, and wrote a program to implement the idea in RSTS/E BASIC+ which he called Test Table Interpreter. This would have been around 1977. I was given the job of re-implementing Test Table Interpreter, first on FORTRAN IV on an RSX-11M system, and then in assembly language on a Zilog Z80 running in a Fluke 8500 voltmeter chassis. A goodly portion of the factory was soon using TTI test programs. I have been fascinated by the idea of cross platform software, and table driven programming, ever since.
 Fast Forward … 1981 – Portland, Oregon … I became aware of a small software house who was creating a new method of producing Data Processing systems using table driven software. Their system, called RDM, was written in Oregon Software Pascal, and ran on RT-11 and RSTS/E. It used a new idea called a relational database. I took the job of porting their code to RSX-11M and then VAX/VMS Pascal.
 Fast Forward … 1991 – Orem, Utah … My sister came to me with a problem. And accounting system she supported, written in Data General Business Basic, was dieing due to lack of hardware. It was too complex, she said, to re-write fo...

[Vernon Cole (vernondcole)]

I found a partial workaround for this bug. The Windows version of BZR can be installed and run on a Linux system using Wine and run using the Wine console. (Start by typing "wine CMD".) It will work correctly to commit changes to an NTSF branch, but cannot do a "push". (Apparently because ssh does not work under Wine.) You can do a "bzr push --no-strict" in Linux to send out the committed changes -- but beware, a simple "bzr status" will set every X bit in the branch.

[Jelmer Vernooij (jelmer)]

I've proposed a branch that makes the check for executability per-tree rather than OS-specific.

The next step would be to extend the per-tree test to see if the current file system actually supports the executable bit. This can be done by:

 * statting a file (probably .bzr/format), and looking at st_dev
 * using getmntent to find the right entry in /proc/mounts
 * checking if the filesystem found is known to support or not support the executable bit

[John Peterson (john-peterson)]

This also occurs with cygwin bzr because cygwin noacl determine the x bit from file contents instead of from the file system.

If there is no desire to version file mode an equivalent to "git config core.filemode false" is a solution.

[Ernst (ernst-blaauw)]

Hi,
Is there anything I can do to help solving this bug? As my repository is used on Linux and Windows, this causes a lot of (unnecessary) changes.
Thanks. Ernst

[Patrick Storz (ede123)]

Also happens when using a Cygwin based bzr (e.g. the one included in MSYS2) and a standalone version of bzr side-by-side.

Extremely annoying... Do you really wonder why nobody wants to use bzr these days? Good thing the Inkscape project has finally decided to move to git so I'm not stuck with these kind of annoyances for much longer.