[win32] `bzr add file` in git tree fails with traceback: _Win32Stat misses st_uid/st_gid members

Bug #967060 reported by Alexander Belchenko
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Bazaar
Fix Released
Medium
Alexander Belchenko
2.4
Fix Released
Medium
Alexander Belchenko
2.5
Fix Released
Medium
Alexander Belchenko

Bug Description

C:\Temp\3>bzr info
Standalone tree (format: git)
Location:
  branch root: .

C:\Temp\3>echo>spam

C:\Temp\3>bzr add spam
adding spam
bzr: ERROR: exceptions.AttributeError: 'bzrlib._walkdirs_win32._Win32Stat' object has no attribute 'st_uid'

Traceback (most recent call last):
  File "bzrlib\commands.pyo", line 920, in exception_to_return_code
  File "bzrlib\commands.pyo", line 1131, in run_bzr
  File "bzrlib\commands.pyo", line 673, in run_argv_aliases
  File "bzrlib\commands.pyo", line 695, in run
  File "bzrlib\cleanup.pyo", line 136, in run_simple
  File "bzrlib\cleanup.pyo", line 166, in _do_with_cleanups
  File "bzrlib\builtins.pyo", line 829, in run
  File "bzrlib\mutabletree.pyo", line 52, in tree_write_locked
  File "C:/Program Files/Bazaar/plugins\git\workingtree.py", line 338, in smart_add
  File "C:/Program Files/Bazaar/plugins\git\workingtree.py", line 206, in _index_add_entry
  File "dulwich\index.pyo", line 388, in index_entry_from_stat
AttributeError: 'bzrlib._walkdirs_win32._Win32Stat' object has no attribute 'st_uid'

bzr 2.5.0 on python 2.6.6 (Windows-XP-5.1.2600-SP3)
arguments: ['C:\\Program Files\\Bazaar\\bzr.EXE', 'add', 'spam']
plugins: acad[0.8.0], bzrtools[2.5.0], colo[0.3.1dev], explorer[1.3.0dev],
    fastimport[0.14.0dev], find_branches[unknown], format1[unknown],
    git[0.6.7], launchpad[2.5.0], qbzr[0.23.0dev], rewrite[0.6.4dev],
    scmproj[0.6.2dev], svn[1.2.1], tiplog[0.0.5dev], undelete[0.2.0],
    x_bit[1.0.0]
encoding: 'cp1251', fsenc: 'mbcs', lang: None

*** Bazaar has encountered an internal error. This probably indicates a
    bug in Bazaar. You can help us fix it by filing a bug report at
        https://bugs.launchpad.net/bzr/+filebug
    including this traceback and a description of the problem.

Tags: win32

Related branches

Revision history for this message
Alexander Belchenko (bialix) wrote :

BTW, implicit add via `bzr mkdir foo` works:

C:\Temp\3>bzr init --git
Created a standalone tree (format: git)

C:\Temp\3>bzr mkdir foo
added foo

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

I guess we'll either have to change bzrlib._walkdirs_win32._Win32Stat to have a st_uid member, or provide a custom index_entry_from_stat function.

Some help with writing such a function from somebody on Windows would be great, as I don't have a way to test here.

affects: bzr-git → dulwich
affects: dulwich → bzr-git
tags: added: win32
Changed in bzr-git:
status: New → Triaged
importance: Undecided → Medium
Revision history for this message
Alexander Belchenko (bialix) wrote :

IPYthon session:

In [1]: import os

In [4]: st = os.stat('.bzr.log')

In [5]: st
Out[5]: (33206, 0L, 0, 0, 0, 0, 4774L, 1320685506, 1320685506, 1320685405)

In [6]: len(st)
Out[6]: 10

In [7]: import stat

In [8]: st[stat.ST_UID]
Out[8]: 0

In [9]: st[stat.ST_GID]
Out[9]: 0

I'm not sure why you need st_uid, but AFAIK these values are always 0 on Windows.

Revision history for this message
Alexander Belchenko (bialix) wrote :

In [10]: st.
st.__add__ st.__le__ st.n_sequence_fields
st.__class__ st.__len__ st.n_unnamed_fields
st.__contains__ st.__lt__ st.st_atime
st.__delattr__ st.__mul__ st.st_ctime
st.__doc__ st.__ne__ st.st_dev
st.__eq__ st.__new__ st.st_gid
st.__ge__ st.__reduce__ st.st_ino
st.__getattribute__ st.__reduce_ex__ st.st_mode
st.__getitem__ st.__repr__ st.st_mtime
st.__getslice__ st.__rmul__ st.st_nlink
st.__gt__ st.__setattr__ st.st_size
st.__hash__ st.__str__ st.st_uid
st.__init__ st.n_fields

In [10]: st.st_uid
Out[10]: 0

In [11]: st.st_gid
Out[11]: 0

Revision history for this message
Alexander Belchenko (bialix) wrote :

It seems bzrlib._walkdirs_win32._Win32Stat does not follow the interface of Python stat object. I wonder why.

Revision history for this message
Alexander Belchenko (bialix) wrote :

From bzrlib._walkdirs_win32:

cdef class _Win32Stat:
    """Represent a 'stat' result generated from WIN32_FIND_DATA"""

    cdef readonly int st_mode
    cdef readonly double st_ctime
    cdef readonly double st_mtime
    cdef readonly double st_atime
    # We can't just declare this as 'readonly' because python2.4 doesn't define
    # T_LONGLONG as a structure member. So instead we just use a property that
    # will convert it correctly anyway.
    cdef __int64 _st_size

    property st_size:
        def __get__(self):
            return self._st_size

    # os.stat always returns 0, so we hard code it here
    cdef readonly int st_dev
    cdef readonly int st_ino

    def __repr__(self):
        """Repr is the same as a Stat object.

        (mode, ino, dev, nlink, uid, gid, size, atime, mtime, ctime)
        """
        return repr((self.st_mode, 0, 0, 0, 0, 0, self.st_size, self.st_atime,
                     self.st_mtime, self.st_ctime))

It seems that implementation just misses declaration of

cdef readonly int st_uid
cdef readonly int st_gid

So, I think we should fix _Win32Stat class in bzrlib.

affects: bzr-git → bzr
Changed in bzr:
status: Triaged → Confirmed
summary: - [win32] `bzr add file` in git tree fails with traceback
+ [win32] `bzr add file` in git tree fails with traceback: _Win32Stat
+ misses st_uid/st_gid members
Changed in bzr:
status: Confirmed → In Progress
assignee: nobody → Alexander Belchenko (bialix)
Changed in bzr:
status: In Progress → Fix Committed
Martin Packman (gz)
Changed in bzr:
milestone: none → 2.6b2
status: Fix Committed → In Progress
status: In Progress → Fix Committed
Revision history for this message
Alexander Belchenko (bialix) wrote :

Patch was merged into 2.4 branch, but not into 2.5 or trunk. Marked as "In progess" as suggested by vila.

Changed in bzr:
status: Fix Committed → In Progress
Vincent Ladeuil (vila)
Changed in bzr:
status: In Progress → Fix Released
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.