bzr incorrectly identifies file as modified (ntfs-3g)

Bug #904950 reported by Ernst
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Bazaar
New
Undecided
Unassigned

Bug Description

I'm running Ubuntu 11.10 64-bit. I have a personal repository which has two check-outs: one one my windows machine and one on this Ubuntu desktop. On Ubuntu, the bzr repository is located on a ntfs-3g mount.

Now I noticed the following behaviour:

1. I update a file on my windows machine and commit to the repository
2. I update my bzr check-out on the Ubuntu desktop
3. Now, I commit on the Ubuntu side (No changes made by me). bzr scans the hard disc for changes and comes up with all the files which were updated in step 2. However, I did not change the files, so those files are incorrectly identified as updated and are unnecessarily committed.

What could cause this behavior?

I'm running:

$ apt-cache policy bzr
bzr:
  Installed: 2.5.0~beta2-1~bazaar1~oneiric1

$ apt-cache policy ntfs-3g
ntfs-3g:
  Installed: 1:2011.4.12AR.4-2ubuntu3

Revision history for this message
Jelmer Vernooij (jelmer) wrote : Re: [Bug 904950] [NEW] bzr incorrectly identifies file as modified (ntfs-3g)

On 12/15/2011 09:45 PM, Ernst wrote:
> Public bug reported:
>
> I'm running Ubuntu 11.10 64-bit. I have a personal repository which has
> two check-outs: one one my windows machine and one on this Ubuntu
> desktop. On Ubuntu, the bzr repository is located on a ntfs-3g mount.
>
> Now I noticed the following behaviour:
>
> 1. I update a file on my windows machine and commit to the repository
> 2. I update my bzr check-out on the Ubuntu desktop
> 3. Now, I commit on the Ubuntu side (No changes made by me). bzr scans
the hard disc for changes and comes up with all the files which were
updated in step 2. However, I did not change the files, so those files
are incorrectly identified as updated and are unnecessarily committed.
>
> What could cause this behavior?
>
Does "bzr status" report the files as changed?

Does "bzr diff" report any changes?

Cheers,

Jelmer

Revision history for this message
Ernst (ernst-blaauw) wrote :

bzr status showes a newly created file as modified

bzr diff shows a lot of garbage, but ends with:
=== modified file 'test.txt' (properties changed: -x to +x)

So, I guess that's the reason: ntfs-3g has been mounted with exec rights?
The fstab entry is:
UUID=E19BD46FD1E4F788 /mnt/documents/ ntfs-3g
defaults,uid=1000,gid=1000 0 0

I assume this behaviour is a intended? For me, this means I have to mount
this share differently. Or is it possible for bzr to discard the execution
property?

On Thu, Dec 15, 2011 at 23:52, Jelmer Vernooij <email address hidden>wrote:

> On 12/15/2011 09:45 PM, Ernst wrote:
> > Public bug reported:
> >
> > I'm running Ubuntu 11.10 64-bit. I have a personal repository which has
> > two check-outs: one one my windows machine and one on this Ubuntu
> > desktop. On Ubuntu, the bzr repository is located on a ntfs-3g mount.
> >
> > Now I noticed the following behaviour:
> >
> > 1. I update a file on my windows machine and commit to the repository
> > 2. I update my bzr check-out on the Ubuntu desktop
> > 3. Now, I commit on the Ubuntu side (No changes made by me). bzr scans
> the hard disc for changes and comes up with all the files which were
> updated in step 2. However, I did not change the files, so those files
> are incorrectly identified as updated and are unnecessarily committed.
> >
> > What could cause this behavior?
> >
> Does "bzr status" report the files as changed?
>
> Does "bzr diff" report any changes?
>
> Cheers,
>
> Jelmer
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/904950
>
> Title:
> bzr incorrectly identifies file as modified (ntfs-3g)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/bzr/+bug/904950/+subscriptions
>

Revision history for this message
Jelmer Vernooij (jelmer) wrote :

On 12/16/2011 10:22 AM, Ernst wrote:
> bzr status showes a newly created file as modified
>
> bzr diff shows a lot of garbage, but ends with:
> === modified file 'test.txt' (properties changed: -x to +x)
>
> So, I guess that's the reason: ntfs-3g has been mounted with exec rights?
> The fstab entry is:
> UUID=E19BD46FD1E4F788 /mnt/documents/ ntfs-3g
> defaults,uid=1000,gid=1000 0 0
>
> I assume this behaviour is a intended? For me, this means I have to mount
> this share differently. Or is it possible for bzr to discard the execution
> property?
Yes, Bazaar assumes that the executable bit will work if it's running on
Linux. Obviously, this isn't always the case as some file systems don't
support this.

I think we already have a bug about that, I'll mark this one as a dupe.

Cheers,

Jelmer

>
>
> On Thu, Dec 15, 2011 at 23:52, Jelmer Vernooij
> <email address hidden>wrote:
>
>> On 12/15/2011 09:45 PM, Ernst wrote:
>>> Public bug reported:
>>>
>>> I'm running Ubuntu 11.10 64-bit. I have a personal repository which has
>>> two check-outs: one one my windows machine and one on this Ubuntu
>>> desktop. On Ubuntu, the bzr repository is located on a ntfs-3g mount.
>>>
>>> Now I noticed the following behaviour:
>>>
>>> 1. I update a file on my windows machine and commit to the repository
>>> 2. I update my bzr check-out on the Ubuntu desktop
>>> 3. Now, I commit on the Ubuntu side (No changes made by me). bzr scans
>> the hard disc for changes and comes up with all the files which were
>> updated in step 2. However, I did not change the files, so those files
>> are incorrectly identified as updated and are unnecessarily committed.
>>>
>>> What could cause this behavior?
>>>
>> Does "bzr status" report the files as changed?
>>
>> Does "bzr diff" report any changes?
>>
>> Cheers,
>>
>> Jelmer
>>
>> --
>> You received this bug notification because you are subscribed to the bug
>> report.
>> https://bugs.launchpad.net/bugs/904950
>>
>> Title:
>> bzr incorrectly identifies file as modified (ntfs-3g)
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/bzr/+bug/904950/+subscriptions
>>
>

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.