bzr status still shows MS Excel file as 'modified' after commit

[Vincent Begaut]

Running Windows 2000, using release bzr 0.15.

In my branch (upgrated from 0.14), bzr status reported a MS Excel file as 'modified'.
After commiting the changes, bzr status still reports the file as 'modified'.
bzr commit --unchanged does not help.
bzr log -verbose shows the new revision, but no reference to the Excel file.

Sounds like the commit skips my Excel file for a reason I cannot track.
If there is additional information I must post to help chase this problem, let me know how.

Thanks.

[John A Meinel (jameinel)]

You may want to upgrade to 0.16, as there are a few bug fixes versus 0.15.

You could try posting the output of My Documents\.bzr.log which should include information about what files it is committing. But at a first guess, that would just say that it isn't committing your excel document.

Can you try running 'bzr diff'. It will probably say "binary files differ", but that at least clarifies that it does think there is a difference which needs to be captured.

When you run 'bzr commit' what arguments are you supplying? (bzr commit foo.txt won't commit the changes to bar.xls)

If you run a plain "bzr commit" and it brings up an editor, does it show that it is going to commit changes to the Excel file?

[Vincent Begaut (dr-virago)]

Thanks for that quick answer.
I just figured out there is a 0.16 released. Now waiting for the weekend is much more enjoyable :-)

Anyway, I just upgraded to 0.16 (no upgrade of my branch was needed) but this does not fix my problem.
Investigating the .bzr.log file reveals that the file reported as 'modified' is not taken in the commit.
I issue a generic "bzr commit" so there is no filter excluding that Excel file.
As you have guessed, "bzr diff" says that both binary files differ.
And to make things worse, the text in the editor does show that it is going to commit the Excel file.

As a simple test, I modified another MS Office document in the branch:
- both files are reported as 'modified'
- both files appear in the popping-up editor when running "bzr commit"
- only the other file is commited (also reported in .bzr.log)

I do not know what the purpose of that command is, but I tried to run "bzr version-info --check-clean".
It reports "clean: False".
Can this help?

Thanks for your support.

[Alexander Belchenko (bialix)]

When you run 'bzr commit' is your files is closed, i.e. do you exit Excel/Word?

Can you repeat your commit with

'bzr --no-aliases --no-plugins commit -m "some message"

?

John, this problem sounds familiar for me. Some (italian?) guy already say about this effect, but he work on UNC path.

[Vincent Begaut (dr-virago)]

The file was last modified 2 days ago, no Excel is running. File is on my local hard drive.
Since I spotted that problem, I did not even try to reopen the file to make sure I did not modify it by accident.

Commiting with 'bzr --no-aliases --no-plugins commit -m "some message"' does not change anything.

And now, for something completely different:
To isolate the bug and keep working with my branch, I copied the directory of my branch (using drag/drop from MS file explorer).
In that new directory, I issued a "bzr status" ... and it reported another Excel file as modified instead!
Though this time, in the copied branch, running 'bzr commit' works and commits that newly reported modified file.

Unless you have any clue about this, or unless anyone is able to reproduce this, I think I will live with that bug.

[Alexander Belchenko (bialix)]

My only guess that it's definitely the bug, but I don't know how to reproduce or debug it.
If you can show your files (i.e. they do not contain confidential data) you can contact with John Meinel off-list, may be John have idea how to at least narrow down the problem.

Only one thing that bite me is internal Bazaar's algorithm to autodetect binary files. May be it's cause problem when the tree contains more than one binary file. I don't know. To my shame I don't understand some Bazaar internals enough related to commit operations.

But I think it's really some latent bug, because it already was reported month or two ago by different person.

[Alexander Belchenko (bialix)]

BTW, can you say what size have the files that cause problems?
Do you use standalone bzr.exe or you have python installed?

[John A Meinel (jameinel)]

My best guess at this point is that we somehow got an incorrect "last modified" sha hash for a file, coupled with a timestamp that makes us think we shouldn't update our check. Said another way... we keep track of the "current" sha hash of every file. But we don't want to read every file to figure out what it is. So we track the last modified timestamp of files, and if the timestamp changes, then we re-read the file and update the sha hash.

What sounds like happened is the timestamp of the file has reset to an older time. And so we aren't re-reading the contents to see what the correct sha hash is.

I went ahead and wrote a plugin to test this sort of thing.

Doing:
cd %APPDATA%\Bazaar\2.0\plugins
bzr branch http://bazaar.launchpad.net/~jameinel/+junk/rebuild-hash-cache rebuild_hash_cache

Should install the plugin for you, and then you can run:

cd $workingdir
bzr rebuild-hash-cache

That should make sure everything is up-to-date, and should also tell you of anything that needed to be updated.

Care to run it for me?

[Vincent Begaut (dr-virago)]

Thanks for these efforts. I will run the plugin as soon as i'm back at work. In 12h or so.

[Alexander Belchenko (bialix)]

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

John A Meinel пишет:
> My best guess at this point is that we somehow got an incorrect "last
> modified" sha hash for a file, coupled with a timestamp that makes us
> think we shouldn't update our check. Said another way... we keep track
> of the "current" sha hash of every file. But we don't want to read every
> file to figure out what it is. So we track the last modified timestamp
> of files, and if the timestamp changes, then we re-read the file and
> update the sha hash.
>
> What sounds like happened is the timestamp of the file has reset to an
> older time. And so we aren't re-reading the contents to see what the
> correct sha hash is.

Older time? It's quiet possible when files copied over network.
Sometime file timestamp corrected on 1 hour or so. Some file managers
even have option to not provide such correction when files copied
from UNC path. Hm...

[µ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGQ5ZezYr338mxwCURArRYAJ4yioY3o9aZ2zbCYICiMz55xPx7nACeOakW
0bx3e5nn46iQqdQ0hsdwLi4=
=zf1v
-----END PGP SIGNATURE-----

[Vincent Begaut (dr-virago)]

Hello,
I had to work on my main branch, so I could not reproduce the problem in there:
I reverted the 'modified' file, and it is exactly the same binary file as the one reverted, which confirms at least that no modification was done on the file reported 'modified'.

Copying the directory of that branch reflected the bug.
I installed and tried the plugin provided by John on that cloned branch, and it updated the hash of the guilty Excel file.
After commiting, 'bzr status' reported no modified file, this apparently fixed the issue.

Additional information I can provide: the size of my binary files is 33kb, 44kb and 80kb.
I have the official Python 2.5 installed (released Sept 2006) and I installed the Bazaar tarball (i.e not the standalone installer).

[Alexander Belchenko (bialix)]

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

Vincent Begaut пишет:
> Hello,
> I had to work on my main branch, so I could not reproduce the problem in there:
> I reverted the 'modified' file, and it is exactly the same binary file as the one reverted, which confirms at least that no modification was done on the file reported 'modified'.
>
> Copying the directory of that branch reflected the bug.
> I installed and tried the plugin provided by John on that cloned branch, and it updated the hash of the guilty Excel file.
> After commiting, 'bzr status' reported no modified file, this apparently fixed the issue.
>
> Additional information I can provide: the size of my binary files is 33kb, 44kb and 80kb.
> I have the official Python 2.5 installed (released Sept 2006) and I installed the Bazaar tarball (i.e not the standalone installer).

Thank you for help.

[µ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGRDZGzYr338mxwCURAgYOAJwLtDeFZf98n4LxH+xk3jx3/GJ+aQCfT0fH
qRsCL6eqOA0lxK7DQuaIUdI=
=9PGh
-----END PGP SIGNATURE-----

[John A Meinel (jameinel)]

If my patch updated the guilty file, then I'm rather confident that we have a timestamp issue. It would seem that Excel might be doing something funny.

Can you tell me what the timestamps reported were?

(I was thinking it probably would say something like moving back in time, etc)

Another possibility is that Excel is modifying the file, but preserving the mtime somehow.

[Vincent Begaut (dr-virago)]

I am afraid I am unable to report the output of "bzr rebuild-hash-cache".
Neither am I able to reproduce the bug in the copied branch.
I will watch over this during the coming days.

[Launchpad Janitor (janitor)]

[Expired for Bazaar because there has been no activity for 60 days.]

[Alexander Belchenko (bialix)]

Revert auto-expired status.

Does this bug still present?

[speedwaystar (speedwaystar)]

I seem to have encountered this bug, except this time with plain text files.

I've attached a folder containing several files which consistently trigger the bug if I initialize the repository in default (2a), 1.14 or 1.14-rich root. Note that it does *NOT* occur if I create a pack-092 repository.

I'm running under Windows 7, using TortoiseBZR 0.58 and Bazaar 2.2.1.

To reproduce:
Delete .bzr tree, initialize Libs folder in 2a repository format, add everything, commit, explore

Expected behaviour:
The working tree should be up to date in Revision 1

Observed behaviour:
Working tree differs from Revision 1

An example unidiff:

=== modified file AceAddon-3.0/AceAddon-3.0.lua
--- AceAddon-3.0/AceAddon-3.0.lua 2010-10-25 14:28:46 +0000
+++ AceAddon-3.0/AceAddon-3.0.lua 2010-08-16 07:52:50 +0000

Looking at the file in question, the creation date is 25/10/2010 10:22 PM, and the modified date is 16/8/2010 3:52 PM. However, another file in the same subfolder has the exact same timestamps, and is *not* being shown as modified.

On closing the explore/unidiff, I get a "bzr: ERROR: [Errno 9] Bad file descriptor" pop up.

Does any of this ring bells?

[Launchpad Janitor (janitor)]

[Expired for Bazaar because there has been no activity for 60 days.]