| commit | d3be651ddd66c87b2c2bba63e97f38cf2ad5e2a6 | |
| author | Christian Halstrick <christian.halstrick@sap.com> | |
| Mon, 6 Oct 2014 12:04:11 +0000 (6 14:04 +0200) | ||
| committer | Matthias Sohn <matthias.sohn@sap.com> | |
| Wed, 8 Oct 2014 22:09:09 +0000 (9 00:09 +0200) | ||
| tree | 7d017056c2b380e23cdc189dcd6149f2225fd6ab | treesnapshot (tar.gz zip) |
| parent | 721cdec164c611b11787a9256ea46b345aa70eea | commitdiff |
Fix ContainerTreeIterator to return on-disk size of a folder
A ContainerTreeIterator always returned 0 as length of a directory. This
was inconsistent with JGits FileTreeIterator which asked the filesystem
object about the length. At least on unix filesystems the file-system
size of the directory was returned which was different from 0. On
Windows 0 was returned by java.io.File.
Because of this inconsistency folders containing submodules often have
been marked as dirty by mistake. The index was filled with data coming
from a FileTreeIterator (length!=0) while the ContainerTreeIterator
returned length==0.
This has been fixed by forcing ContainerTreeIterator to ask the
filesystem for the length of a folder.
Bug: 391280
Change-Id: I4b75ee1e875ead1d0d2f772056aca918d37d3ffd
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
A ContainerTreeIterator always returned 0 as length of a directory. This
was inconsistent with JGits FileTreeIterator which asked the filesystem
object about the length. At least on unix filesystems the file-system
size of the directory was returned which was different from 0. On
Windows 0 was returned by java.io.File.
Because of this inconsistency folders containing submodules often have
been marked as dirty by mistake. The index was filled with data coming
from a FileTreeIterator (length!=0) while the ContainerTreeIterator
returned length==0.
This has been fixed by forcing ContainerTreeIterator to ask the
filesystem for the length of a folder.
Bug: 391280
Change-Id: I4b75ee1e875ead1d0d2f772056aca918d37d3ffd
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>