configuration or command option to ignore filesystem permission changes

[Martin Pool]

In some cases users on unix would like to ignore apparent changes in workingtree execute bits. As one example the user may have their workingtrees mounted on a CIFS or VFAT filesystem on unix: the files apparently have mode bits but they can't be set reproducibly. Instead we would presumably store them just in the dirstate.

I can imagine wanting to set this either as a per-location configuration, or as an option to diff/status/commit.

Comes from https://answers.launchpad.net/bzr/+question/34332

[Keith (kistler)]

This is also an issue when working under windows with cygwin and tortoise bzr in combination. If you branch with one of the tools, and attempt to commit or look at the status - many if not all of the files in your working tree are flagged as the permissions have been modified... This is prevents people from being able to take advantage tortoise bzr and cygwin in parallel.

[Keith (kistler)]

Update, I was partially wrong. The issue occurs when you do a checkout with tortoise bzr, then use "bzr status" (or commit etc..) from cygwin is when it believes that the file permissions were deliberately changed. It does not seem to be an issue when you branch with command line bzr from cygwin! Also - if you branch with tortoise bzr - before you do any work, use cygwin, go to your working directory, run "bzr revert". You will not lose any work (as you have done none) and it will put the working tree in a state that matches the repository - and TortoiseBzr appears to continue working as desired.

This really only applies to those who wish to use command line and ui interfaces for bzr..

[John A Meinel (jameinel)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Keith wrote:
> Update, I was partially wrong. The issue occurs when you do a checkout
> with tortoise bzr, then use "bzr status" (or commit etc..) from cygwin
> is when it believes that the file permissions were deliberately changed.
> It does not seem to be an issue when you branch with command line bzr
> from cygwin! Also - if you branch with tortoise bzr - before you do any
> work, use cygwin, go to your working directory, run "bzr revert". You
> will not lose any work (as you have done none) and it will put the
> working tree in a state that matches the repository - and TortoiseBzr
> appears to continue working as desired.
>
> This really only applies to those who wish to use command line and ui
> interfaces for bzr..
>

You can use the 'bzr.exe' that comes with TBzr, and *not* use cygwin's bzr.

The issue is that cygwin is adding posix-like semantics that don't exist
natively on Windows. So a native Windows app doesn't *see* something
like 'executable', because that isn't tracked in NFTS/FAT in the same
way. (I'm not entirely sure where cygwin stores the exec bit.)

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAksyWDkACgkQJdeBCYSNAANQwACcD1OV8achyQLwcyqg1qk64n3u
JuIAoIRlLLr2frbsDKIRn3WBJ8C/Y4ir
=49O3
-----END PGP SIGNATURE-----

[Steve Sexton (steve-sexton)]

My use case:

* Working on a C++ codebase that runs on Windows and Linux
* Desire to store Linux-specific files (vendor exes) with the source tree
* When code is updated/checked out on Windows (using Cygwin bzr) the +x bit is lost. Suggested workaround of using bzr revert is ineffective for me.
* Probably relevant: In Cygwin /etc/fstab, the drive is mounted with 'noacl' option to prevent Cygwin from mucking up Windows file permissions.

Agreed the root cause of this problem is the terrible way that recent versions of Cygwin handle file permissions. File permission handling in Cygwin has been poor ever since the 'nontsec' option was removed.

Agreed that one solution to this problem is not to use the Cygwin version of bzr.

For my use case, a per-user configuration option to ignore and preserve the +x bit would be ideal. In other words an option I can set on Cygwin side only that causes bzr not to see the +x bit at all, but that doesn't lose any +x on the file that may have been set in the Linux environment.

[Sondra Kinsey (sondra.kinsey)]

I have the same problem working with a bzr branch on a FAT32 thumb drive using a mac. I really wish I could ignore executable permissions changes on this drive. Do you have a suggestion for a practical workaround?

[Sondra Kinsey (sondra.kinsey)]

As a fascinating addition, I have discovered that bzr somehow does in fact turn executable bit monitoring on and off somehow.

I have two identical branches, yet one recognizes changes to the executable bit, and the other does not.
They are currently at the same revno, with the same working tree, on the same file system. Yet one notices that the executable bit has changed and the other does not.
I dual boot Windows and Linux, and I think perhaps grill-2 was made using Linux (but still on the NTFS file system), whereas grill may have been made using windows.
I frequently have issues with branches I work and test in both Windows and Linux and various file systems. Is there a setting I can set somehow to make bzr ignore and then not ignore the executable bit for files?

I have attached the two identical working trees for your convenience.

Environment information:

bzr --version
Bazaar (bzr) 2.5.1
  Python interpreter: C:\Program Files\Bazaar\python26.dll 2.6.6
  Python standard library: C:\Program Files\Bazaar\lib\library.zip
  Platform: Windows-Vista-6.0.6002-SP2

[Alfred Morgan (zectbumo)]

https://msdn.microsoft.com/en-us/commandline/wsl/
You might want to think about raising this priority now that Windows has a Linux subsystem you will most likely run into the issue as I already have.