win -> linux: only properties changed

With newer bzr, it will show you *what* property changed. Under Linux, did you check it out on a VFAT partition? My guess is that somehow all the files are now marked Executable, (or now all not marked executable, but the former is more likely).

You might just simply change the mount defaults on the vfat partition, or check it out on ext3 or some other native linux filesystem that can preserve executable bits.

Indeend, I checked it out on a vfat (FAT32) formated partition.
But the inital repository was also created on a Windows partition on an entriely Win XP computer.

Can I tell bzr to ignore such changes?

My current fstab setting in Ubuntu goes like:
/dev/sda2 on /media/shared type vfat (rw,utf8,shortname=winnt,umask=000,gid=46,uid=1000)

How would you set it to avoid to have all these minor changes due to changed operation system?

Kind regards & thanks for the help.

On Tue, May 27, 2008 at 9:14 AM, Tim
<email address hidden> wrote:
> Question #34332 on Bazaar changed:
> https://answers.edge.launchpad.net/bzr/+question/34332
>
> Status: Answered => Solved
>
> Tim confirmed that the question is solved:
> Indeend, I checked it out on a vfat (FAT32) formated partition.
> But the inital repository was also created on a Windows partition on an entriely Win XP computer.
>
> Can I tell bzr to ignore such changes?
>
> My current fstab setting in Ubuntu goes like:
> /dev/sda2 on /media/shared type vfat (rw,utf8,shortname=winnt,umask=000,gid=46,uid=1000)
>
> How would you set it to avoid to have all these minor changes due to
> changed operation system?

I think you want to set the fmask=0111 (or =0117) mount option, which
will tell the kernel not to show the execute bit as set on all the
files.

--
Martin <http://launchpad.net/~mbp/>

The last comment really solved my problem.
We should check whether this is also well implemented in Ubuntu fstab settings. Maybe this can be taken care of in the Update-Manager.

Thanks for all answers.

On Wed, May 28, 2008 at 9:55 AM, Tim
<email address hidden> wrote:
> Question #34332 on Bazaar changed:
> https://answers.launchpad.net/bzr/+question/34332
>
> Tim posted a new comment:
> The last comment really solved my problem.
> We should check whether this is also well implemented in Ubuntu fstab settings. Maybe this can be taken care of in the Update-Manager.

Good point. Could you raise that issue in Ubuntu and post a link here please?

--
Martin <http://launchpad.net/~mbp/>

Hello,
This issue returned on another project whose files have different permissions because it was
1) either started on a wrongly mounted vfat partition and then continued on a ext partition
2) or started on linux with different partitions.

comment to 1)
this problem between different filysystem types of which one does not store file permissions properly does only occour when I checkout to a computer running linux but storing on a mounted vfat partition. When chaging between a Windows machine with vfat or ntfs and a linux machine with ext this problem does not occour!
I still need to mout a vfat partition on my machine because it allows me to use a dual boot setup. Sometimes I want to test my program if it runs on Windows...

comment on 2)
This may arise when a devloper using linux sets all Python scripts to executable permissions in order to run them immediately. On the others files like documentation the developer would use normal read-write permissions. This leads to mixed permissions which will cause the problem in bazaar when developing on Windows later on.

I would therefore ask
1) if it is technically feasibile to configure bazaar to ignore file permissions at all. Shall I file a feature request here?
2) how I could get around my problem in the current state of bazaar. recommending using linux filsystem types only is not an option for a crossplattform DVCS. The answer given in the comment above to change mount options does only mitigate the problem for projects with correct permissions which correspond to the vfat mount options.

Sorry for my rather long comment.
But this really bothers me at the moment. At least it should be written in the bazaar documentation that before commiting persons working in a crossplatform environment should think of the permissions problem.

I will really appreciate your help, hints and tips.
Kind regards.

This question was expired because it remained in the 'Open' state without activity for the last 15 days.

>I would therefore ask
>1) if it is technically feasibile to configure bazaar to ignore file permissions at all. Shall I file a feature request here?

It should be possible; I filed https://bugs.launchpad.net/bzr/+bug/240294

>2) how I could get around my problem in the current state of bazaar. recommending using linux filsystem types only is not an option for a crossplattform DVCS. The answer given in the comment above to change mount options does only mitigate the problem for projects with correct permissions which correspond to the vfat mount options.

As far as I can see this problem will only occur when you're on an OS that normally supports x bits but a filesystem that does not. A tree that's sometimes checked out on ext3 linux and sometimes on ntfs win32 should not have problems.

In regards to the above comment - it goes one step further than that: https://bugs.launchpad.net/bzr/+bug/240294/comments/1

I found a potential work around for some use cases... https://bugs.launchpad.net/bzr/+bug/240294

I'm having one heck of a time with this. Trying to hook up a Synology NAS in a web development agency. Developers use Windows and connect to it using Samba/CIFS, and virtualized web servers connect to it using NFS. Problem is that the permissions on it end up being set so that to +x for all files being saved. Files being committed on the network share, either through Windows or NFS, see the permission as +x. I don't want to have all these website files floating around as +x on the live server when we do a merge to get the changes live.

Would absolutely love the ability to just ignore the exec bit, other workarounds are just not working. Tried file system ACLs, network ACLs, umask/fmask, etc... I'm sure there is some work around but it would be so nice if we could just disable exec bit tracking through the BZR configuration file.