{"thread":{"id":"14569","subject":"[PATCH] Fix update-index --refresh for submodules if stat(2) returns st_size 0","startedAt":"2008-07-21T17:35:11Z","lastAt":"2008-07-29T10:49:54Z","messageCount":41,"participants":["Alex Riesen","Johannes Schindelin","Johannes Sixt","Junio C Hamano","Anton Mostovoy","Linus Torvalds","David Brown","Petr Baudis"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"84206","messageId":"20080721173511.GB5387@steel.home","threadId":"14569","inReplyTo":null,"subject":"[PATCH] Fix update-index --refresh for submodules if stat(2) returns st_size 0","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-07-21T17:35:11Z","receivedAt":"2008-07-21T17:35:11Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"For example - Cygwin.\n\nSigned-off-by: Alex Riesen <raa.lkml@gmail.com>\n---\n\nCan MSys folks please try it? I noticed it when the test\nt2103-update-index-ignore-missing.sh (the 5th case) started failing.\n\n read-cache.c |    2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/read-cache.c b/read-cache.c\nindex a50a851..eb30c20 100644\n--- a/read-cache.c\n+++ b/read-cache.c\n@@ -281,7 +281,7 @@ int ie_modified(const struct index_state *istate,\n \t * the length field is zero.  For other cases the ce_size\n \t * should match the SHA1 recorded in the index entry.\n \t */\n-\tif ((changed & DATA_CHANGED) && ce->ce_size != 0)\n+\tif ((changed & DATA_CHANGED) && (ce->ce_size != 0 || S_ISGITLINK(ce->ce_mode)))\n \t\treturn changed;\n \n \tchanged_fs = ce_modified_check_fs(ce, st);\n-- \n1.5.6.4.452.g7b2a\n"},{"id":"84215","messageId":"alpine.DEB.1.00.0807211917440.8986@racer","threadId":"14569","inReplyTo":"20080721173511.GB5387@steel.home","subject":"Re: [PATCH] Fix update-index --refresh for submodules if stat(2) returns st_size 0","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-21T18:20:43Z","receivedAt":"2008-07-21T18:20:43Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 21 Jul 2008, Alex Riesen wrote:\n\n> For example - Cygwin.\n\nPlease enhance: your oneline is too long, and your commit message body too \nshort.\n\n> Can MSys folks please try it? I noticed it when the test\n> t2103-update-index-ignore-missing.sh (the 5th case) started failing.\n\nSince M$' documentation says \"This member does not have a meaning for \ndirectories.\" about the member nFileSizeLow of WIN32_FILE_ATTRIBUTE_DATA \nwhich we use to implement a sane \"lstat()\", I think this bug hits MinGW \n(not MSys) as well.\n\nCiao,\nDscho\n"},{"id":"84232","messageId":"20080721194322.GA4013@blimp.local","threadId":"14569","inReplyTo":"alpine.DEB.1.00.0807211917440.8986@racer","subject":"Re: [PATCH] Fix update-index --refresh for submodules if stat(2) returns st_size 0","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-07-21T19:43:22Z","receivedAt":"2008-07-21T19:43:22Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Johannes Schindelin, Mon, Jul 21, 2008 20:20:43 +0200:\n> Hi,\n> \n> On Mon, 21 Jul 2008, Alex Riesen wrote:\n> \n> > For example - Cygwin.\n> \n> Please enhance: your oneline is too long, and your commit message body too \n> short.\n\nWell, I'm really not sure. I just found this difference between linux\nand cygwin (st_stat is 0 for dirs on cygwin). Than I noticed that the\nroutine where I made the change explicitely checks for st_size not\nbeing 0. I must admit I can't make much out of comment, and hope this\ndiscussion will help to clear the check up.\n\n> > Can MSys folks please try it? I noticed it when the test\n> > t2103-update-index-ignore-missing.sh (the 5th case) started failing.\n> \n> Since M$' documentation says \"This member does not have a meaning for \n> directories.\" about the member nFileSizeLow of WIN32_FILE_ATTRIBUTE_DATA \n> which we use to implement a sane \"lstat()\", I think this bug hits MinGW \n> (not MSys) as well.\n\nCould you, just for completeness, try? I don't have mingw at hand\nand SUSv3 (http://www.opengroup.org/onlinepubs/009695399/toc.htm)\ndoes not tells much too. No UNIX system I know about has it 0 for\ndirectories.\n"},{"id":"84252","messageId":"alpine.DEB.1.00.0807220126020.3407@eeepc-johanness","threadId":"14569","inReplyTo":"20080721194322.GA4013@blimp.local","subject":"Re: [PATCH] Fix update-index --refresh for submodules if stat(2) returns st_size 0","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-21T23:26:54Z","receivedAt":"2008-07-21T23:26:54Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 21 Jul 2008, Alex Riesen wrote:\n\n> Johannes Schindelin, Mon, Jul 21, 2008 20:20:43 +0200:\n>\n> > Alex wrote:\n> > \n> > > Can MSys folks please try it? I noticed it when the test \n> > > t2103-update-index-ignore-missing.sh (the 5th case) started failing.\n> > \n> > Since M$' documentation says \"This member does not have a meaning for \n> > directories.\" about the member nFileSizeLow of \n> > WIN32_FILE_ATTRIBUTE_DATA which we use to implement a sane \"lstat()\", \n> > I think this bug hits MinGW (not MSys) as well.\n> \n> Could you, just for completeness, try?\n\nNo, I cannot.  I have no Windows machine.\n\nCiao,\nDscho\n"},{"id":"84291","messageId":"4885897C.8010401@viscovery.net","threadId":"14569","inReplyTo":"20080721173511.GB5387@steel.home","subject":"Re: [PATCH] Fix update-index --refresh for submodules if stat(2) returns st_size 0","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2008-07-22T07:17:16Z","receivedAt":"2008-07-22T07:17:16Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Alex Riesen schrieb:\n> Can MSys folks please try it? I noticed it when the test\n> t2103-update-index-ignore-missing.sh (the 5th case) started failing.\n\nI tested it. mingw.git does suffer from the problem, and this fixes it.\n\nBut!\n\n> +\tif ((changed & DATA_CHANGED) && (ce->ce_size != 0 || S_ISGITLINK(ce->ce_mode)))\n\nDoes this mean that ce->ce_size is non-zero for gitlinks, at least on\nUnix? Is this value useful in anyway? I don't think so. Then it shouldn't\nbe a random value that lstat() happens to return.\n\n-- Hannes\n"},{"id":"84305","messageId":"7vbq0qnxyi.fsf@gitster.siamese.dyndns.org","threadId":"14569","inReplyTo":"20080721194322.GA4013@blimp.local","subject":"Re: [PATCH] Fix update-index --refresh for submodules if stat(2) returns st_size 0","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-22T08:07:49Z","receivedAt":"2008-07-22T08:07:49Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alex Riesen <raa.lkml@gmail.com> writes:\n\n> Johannes Schindelin, Mon, Jul 21, 2008 20:20:43 +0200:\n>> Hi,\n>> \n>> On Mon, 21 Jul 2008, Alex Riesen wrote:\n>> \n>> > For example - Cygwin.\n>> \n>> Please enhance: your oneline is too long, and your commit message body too \n>> short.\n>\n> Well, I'm really not sure. I just found this difference between linux\n> and cygwin (st_stat is 0 for dirs on cygwin). Than I noticed that the\n> routine where I made the change explicitely checks for st_size not\n> being 0. I must admit I can't make much out of comment, and hope this\n> discussion will help to clear the check up.\n\nThe cached stat information in the index is used to speed up comparison\nbetween \"the last staged data\" and what is in the working tree.\nie_match_stat() compares ce_xxx fields with the result from lstat(2) we\njust did, and if there are differences, we take it as a sign that what's\nin the working tree is different from what we saw when we updated the\nindex entry.\n\nBut there is a twist.\n\nOrdinarily, when an entry enteres the index, the hash of the blob contents\ngoes along with the lstat(2) information taken from the file that supplied\nthe contents.  However there are some cases we populate the index without\nlstat(2).  update-index --cacheinfo, update-index --index-info are two\nexamples, and when they add index entries, they leave ce_size field to\nzero.  ie_match_stat() will compare that zero ce_size with the size\ninformation obtained from the working tree, and declare (falsely) that\n\"what's in the working tree is different -- it can never match, and there\nis no point trying to re-index to see if they actually match\", even though\nthe reason ce_size is zero is *not* because we observed the size of the\nworking tree file *was* zero when we indexed it the last time (it is zero\nmerely because we haven't looked at it yet).  The ce_modified_check_fs()\ncall is there to deal with this \"we cannot trust the ce_xxx fields\" case.\n\nI however have to wonder if you also need to touch the end of\nce_match_stat_basic() that checks for zero sized cache entry.\n"},{"id":"84335","messageId":"20080722164604.GA3766@blimp.local","threadId":"14569","inReplyTo":"4885897C.8010401@viscovery.net","subject":"Re: [PATCH] Fix update-index --refresh for submodules if stat(2) returns st_size 0","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-07-22T16:46:04Z","receivedAt":"2008-07-22T16:46:04Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Johannes Sixt, Tue, Jul 22, 2008 09:17:16 +0200:\n> Alex Riesen schrieb:\n> > Can MSys folks please try it? I noticed it when the test\n> > t2103-update-index-ignore-missing.sh (the 5th case) started failing.\n> \n> I tested it. mingw.git does suffer from the problem, and this fixes it.\n> \n\nYes, I did too (at work).\n\n> > +\tif ((changed & DATA_CHANGED) && (ce->ce_size != 0 || S_ISGITLINK(ce->ce_mode)))\n> \n> Does this mean that ce->ce_size is non-zero for gitlinks, at least on\n> Unix?\n\nIt is non-zero for directories (which is what gitlinks are in working\ndirectories) on UNIX operating systems I met.\n\n> Is this value useful in anyway?\n\nSometimes it is (the size a directory takes on storage)\n\n> I don't think so. Then it shouldn't be a random value that lstat()\n> happens to return.\n\nThe problem is: it is not random. I even suspect that Windows is the\nONLY system which has st_size 0 for directories.\n"},{"id":"84334","messageId":"20080722164941.GB3766@blimp.local","threadId":"14569","inReplyTo":"7vbq0qnxyi.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Fix update-index --refresh for submodules if stat(2) returns st_size 0","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-07-22T16:49:41Z","receivedAt":"2008-07-22T16:49:41Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Junio C Hamano, Tue, Jul 22, 2008 10:07:49 +0200:\n> I however have to wonder if you also need to touch the end of\n> ce_match_stat_basic() that checks for zero sized cache entry.\n\nI frankly don't know.\n"},{"id":"84337","messageId":"48861203.80106@viscovery.net","threadId":"14569","inReplyTo":"20080722164604.GA3766@blimp.local","subject":"Re: [PATCH] Fix update-index --refresh for submodules if stat(2) returns st_size 0","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2008-07-22T16:59:47Z","receivedAt":"2008-07-22T16:59:47Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Alex Riesen schrieb:\n> Johannes Sixt, Tue, Jul 22, 2008 09:17:16 +0200:\n>> Alex Riesen schrieb:\n>>> +\tif ((changed & DATA_CHANGED) && (ce->ce_size != 0 || S_ISGITLINK(ce->ce_mode)))\n>> Does this mean that ce->ce_size is non-zero for gitlinks, at least on\n>> Unix?\n> \n> It is non-zero for directories (which is what gitlinks are in working\n> directories) on UNIX operating systems I met.\n> \n>> Is this value useful in anyway?\n> \n> Sometimes it is (the size a directory takes on storage)\n\nSure; but is ce->ce_size of gitlinks useful?\n\n-- Hannes\n"},{"id":"84343","messageId":"7vy73tltf5.fsf@gitster.siamese.dyndns.org","threadId":"14569","inReplyTo":"4885897C.8010401@viscovery.net","subject":"Re: [PATCH] Fix update-index --refresh for submodules if stat(2) returns st_size 0","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-22T17:28:46Z","receivedAt":"2008-07-22T17:28:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt <j.sixt@viscovery.net> writes:\n\n>> +\tif ((changed & DATA_CHANGED) && (ce->ce_size != 0 || S_ISGITLINK(ce->ce_mode)))\n>\n> Does this mean that ce->ce_size is non-zero for gitlinks, at least on\n> Unix? Is this value useful in anyway? I don't think so. Then it shouldn't\n> be a random value that lstat() happens to return.\n\nThese ce_xxx fields are the values we read from lstat(2) when the user\ntold us to stage that working tree entity, be it a regular file, a\nsymlink, or a directory that is a submodule.  The only thing required for\nthem is that they are stable (i.e. if you haven't touched the working tree\nentity, the value stays the same), and changes across modification.  The\nvalue itself does not have to \"mean\" anything.\n\nWhen trying to see if the user has changes in the working tree entity\nsince the last such staging of the path, we compare that value with what\ncomes back from lstat(2), before actually comparing the contents.  If the\nfilesize changed, they cannot be the same and the code says you have\nmodified it without having to look at the contents.\n\n\tSide note.  This is why you need to be careful after modifying\n\tautocrlf related configuration and attributes.  If you had CRLF\n\tcontents in the working tree that was incorrectly staged as-is,\n\tthen switch autocrlf-on, and \"git add\" to fix the staged copy to\n\tbe LF-terminated, we say \"it's unchanged and we do not bother\n\trehashing\" by comparing the ce_xxx fields without looking at the\n\tcontents (this is an absolutely necessary optimization to make\n\t\"git add .\"  usable), because ce_size records the size of CRLF\n\tversion you have in the working tree, and you haven't changed the\n\tworking tree file in this sequence above.\n\n        Removing the file and checking things out would be the most\n\tstraightforward solution in such a case.\n\nWe used to include ce_dev (taken from struct stat.st_dev) in the list of\nfields to cache and compare to detect changes, but that is now excluded\nbecause it is not stable (see comments in read-cache.c).  If the directory\nsize is unstable, perhaps it would be better to force it to some fixed\nmagic value so that it is not used by this \"quick change detection\" check.\n\nIf you network-mount the same directory from POSIX and windows, the former\nmay give \"storage size of the directory\" while the latter may give 0.\nThis would mean that you would need a \"update-index --refresh\" when you\nswitch between such machines.\n"},{"id":"84351","messageId":"20080722193901.GA5113@blimp.local","threadId":"14569","inReplyTo":"7vy73tltf5.fsf@gitster.siamese.dyndns.org","subject":"[PATCH] Build configuration to skip ctime for modification test","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-07-22T19:39:01Z","receivedAt":"2008-07-22T19:39:01Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On Windows, the only file attribute we need (executable) cannot be\nused, so ctime can be ignored as well. Change time is updated when\nfile attributes were changed (or it is written to, but in this case,\nmtime is updated as well).\n\nSigned-off-by: Alex Riesen <raa.lkml@gmail.com>\n---\n\nJunio C Hamano, Tue, Jul 22, 2008 19:28:46 +0200:\n> Johannes Sixt <j.sixt@viscovery.net> writes:\n> \n> >> +\tif ((changed & DATA_CHANGED) && (ce->ce_size != 0 || S_ISGITLINK(ce->ce_mode)))\n> >\n> > Does this mean that ce->ce_size is non-zero for gitlinks, at least on\n> > Unix? Is this value useful in anyway? I don't think so. Then it shouldn't\n> > be a random value that lstat() happens to return.\n> \n> These ce_xxx fields are the values we read from lstat(2) when the user\n> told us to stage that working tree entity, be it a regular file, a\n> symlink, or a directory that is a submodule.  The only thing required for\n> them is that they are stable (i.e. if you haven't touched the working tree\n> entity, the value stays the same), and changes across modification.  The\n> value itself does not have to \"mean\" anything.\n\nThis reminds me... We can't use the only file attribute we care about\non Windows, so we can as well skip check for ctime. Besides, Google\nDesktop Search keeps changing ctime when crawling files (ok, GDS is a\nmajor usability nuance anyway, but the point is - we don't use the\nfile attribute).\n\n read-cache.c |    2 ++\n 1 files changed, 2 insertions(+), 0 deletions(-)\n\ndiff --git a/read-cache.c b/read-cache.c\nindex a50a851..c4f2718 100644\n--- a/read-cache.c\n+++ b/read-cache.c\n@@ -181,8 +181,10 @@ static int ce_match_stat_basic(struct cache_entry *ce, struct stat *st)\n \t}\n \tif (ce->ce_mtime != (unsigned int) st->st_mtime)\n \t\tchanged |= MTIME_CHANGED;\n+#ifndef NO_TRUSTABLE_FILEMODE\n \tif (ce->ce_ctime != (unsigned int) st->st_ctime)\n \t\tchanged |= CTIME_CHANGED;\n+#endif\n \n \tif (ce->ce_uid != (unsigned int) st->st_uid ||\n \t    ce->ce_gid != (unsigned int) st->st_gid)\n-- \n1.6.0.rc0.41.g70446\n"},{"id":"84357","messageId":"alpine.DEB.1.00.0807222115440.8986@racer","threadId":"14569","inReplyTo":"20080722193901.GA5113@blimp.local","subject":"Re: [PATCH] Build configuration to skip ctime for modification test","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-22T20:17:21Z","receivedAt":"2008-07-22T20:17:21Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 22 Jul 2008, Alex Riesen wrote:\n\n> +#ifndef NO_TRUSTABLE_FILEMODE\n>  \tif (ce->ce_ctime != (unsigned int) st->st_ctime)\n>  \t\tchanged |= CTIME_CHANGED;\n> +#endif\n\nSurely you meant trust_executable_bit instead, right?\n\nOtherwise, if you really want to tell at compile time,I think for clarity \nyou have to introduce another #define, since NO_TRUSTABLE_FILEMODE \ndefinitely says something different than CTIME_IS_USELESS.\n\nCiao,\nDscho\n"},{"id":"84359","messageId":"20080722203128.GB5113@blimp.local","threadId":"14569","inReplyTo":"alpine.DEB.1.00.0807222115440.8986@racer","subject":"Re: [PATCH] Build configuration to skip ctime for modification test","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-07-22T20:31:29Z","receivedAt":"2008-07-22T20:31:29Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Johannes Schindelin, Tue, Jul 22, 2008 22:17:21 +0200:\n> Hi,\n> \n> On Tue, 22 Jul 2008, Alex Riesen wrote:\n> \n> > +#ifndef NO_TRUSTABLE_FILEMODE\n> >  \tif (ce->ce_ctime != (unsigned int) st->st_ctime)\n> >  \t\tchanged |= CTIME_CHANGED;\n> > +#endif\n> \n> Surely you meant trust_executable_bit instead, right?\n\nNo. Just what I said: we don't have filemode (like \"at all\") - so no\nctime as well. But maybe you're right, and trust_executable_bit is\nmore flexible. Or maybe both (the #ifdef _and_ trust_executable_bit)\nand must be used...\n\n> Otherwise, if you really want to tell at compile time,I think for clarity \n> you have to introduce another #define, since NO_TRUSTABLE_FILEMODE \n> definitely says something different than CTIME_IS_USELESS.\n\nI had that at first (NO_DEPENDABLE_CTIME, than IGNORE_CTIME), than\ndeemed it excessive.\n"},{"id":"84411","messageId":"7vr69lihkt.fsf@gitster.siamese.dyndns.org","threadId":"14569","inReplyTo":"20080722203128.GB5113@blimp.local","subject":"Re: [PATCH] Build configuration to skip ctime for modification test","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-23T00:12:50Z","receivedAt":"2008-07-23T00:12:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alex Riesen <raa.lkml@gmail.com> writes:\n\n> Johannes Schindelin, Tue, Jul 22, 2008 22:17:21 +0200:\n>> Hi,\n>> \n>> On Tue, 22 Jul 2008, Alex Riesen wrote:\n>> \n>> > +#ifndef NO_TRUSTABLE_FILEMODE\n>> >  \tif (ce->ce_ctime != (unsigned int) st->st_ctime)\n>> >  \t\tchanged |= CTIME_CHANGED;\n>> > +#endif\n>> \n>> Surely you meant trust_executable_bit instead, right?\n>\n> No. Just what I said: we don't have filemode (like \"at all\") - so no\n> ctime as well. But maybe you're right, and trust_executable_bit is\n> more flexible. Or maybe both (the #ifdef _and_ trust_executable_bit)\n> and must be used...\n>\n>> Otherwise, if you really want to tell at compile time,I think for clarity \n>> you have to introduce another #define, since NO_TRUSTABLE_FILEMODE \n>> definitely says something different than CTIME_IS_USELESS.\n>\n> I had that at first (NO_DEPENDABLE_CTIME, than IGNORE_CTIME), than\n> deemed it excessive.\n\nWhy is it excessive?  My initial reaction was \"what does trustable\nfilemode nor trust_executable_bit has anything to do with ctime\".  Please\nexplain.\n"},{"id":"84528","messageId":"F06D8607A852466D93AE8BF2AF224893@chi.orbitz.net","threadId":"14569","inReplyTo":"20080722203128.GB5113@blimp.local","subject":"git svn throws locale related error when built from source","fromName":"Anton Mostovoy","fromEmail":"a@mostovoy.net","sentAt":"2008-07-23T16:00:23Z","receivedAt":"2008-07-23T16:00:23Z","isPatch":false,"sender":{"key":"a@mostovoy.net","avatar":null},"body":"Hi\n\nI built git 1.5.6.3 manually (no package with 1.5.4+ on gutsy), and I am\ngetting the error below when running 'git svn rebase'. \nsvn works fine on its own though.  \nThe default locale is set to en_US.UTF-8\n\nsvn: error: cannot set LC_ALL locale\nsvn: error: environment variable LANG is en_US.UTF-8\nsvn: error: please check that your locale name is correct\n\nI found a workaround that works, but it would be nice to have it work\nproperly.\n$> LANG= git svn rebase\"\n\nThanks in advance.\n-Anton\n"},{"id":"84543","messageId":"20080723164614.GB5283@blimp.local","threadId":"14569","inReplyTo":"7vr69lihkt.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Build configuration to skip ctime for modification test","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-07-23T16:46:14Z","receivedAt":"2008-07-23T16:46:14Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Junio C Hamano, Wed, Jul 23, 2008 02:12:50 +0200:\n> >> Otherwise, if you really want to tell at compile time,I think for clarity \n> >> you have to introduce another #define, since NO_TRUSTABLE_FILEMODE \n> >> definitely says something different than CTIME_IS_USELESS.\n> >\n> > I had that at first (NO_DEPENDABLE_CTIME, than IGNORE_CTIME), than\n> > deemed it excessive.\n> \n> Why is it excessive?  My initial reaction was \"what does trustable\n> filemode nor trust_executable_bit has anything to do with ctime\".  Please\n> explain.\n\nBecause exactly the file mode (the executable bit) is the reason for\nchecking ctime. Otherwise there is no point: Git doesn't save any\nother data which when changed cause a ctime update. And exactly the\nfile mode is completely broken on that cygwin thing. Which is\nprecisely pointed by NO_TRUSTABLE_FILEMODE. Hence - just it.\n"},{"id":"84548","messageId":"alpine.DEB.1.00.0807231757550.8986@racer","threadId":"14569","inReplyTo":"20080723164614.GB5283@blimp.local","subject":"Re: [PATCH] Build configuration to skip ctime for modification test","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-23T16:59:02Z","receivedAt":"2008-07-23T16:59:02Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 23 Jul 2008, Alex Riesen wrote:\n\n> Because exactly the file mode (the executable bit) is the reason for\n> checking ctime.\n\nBut ctime is broken on Windows.  Because ctime is supposed to change \nwhenever the _inode_ changes.\n\nYou have to admit that saying \"I ignore the ctime because the executable \nbit is broken\" must leave the reader puzzled.\n\nCiao,\nDscho\n"},{"id":"84585","messageId":"20080723191647.GF5283@blimp.local","threadId":"14569","inReplyTo":"alpine.DEB.1.00.0807231757550.8986@racer","subject":"Re: [PATCH] Build configuration to skip ctime for modification test","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-07-23T19:16:47Z","receivedAt":"2008-07-23T19:16:47Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Johannes Schindelin, Wed, Jul 23, 2008 18:59:02 +0200:\n> On Wed, 23 Jul 2008, Alex Riesen wrote:\n> \n> > Because exactly the file mode (the executable bit) is the reason for\n> > checking ctime.\n> \n> But ctime is broken on Windows.  Because ctime is supposed to change \n> whenever the _inode_ changes.\n\nIt is not that it is broken. We just don't need it, because the st_mode\nis not used, and the rest of inode information is not used anyway.\n\n> You have to admit that saying \"I ignore the ctime because the executable \n> bit is broken\" must leave the reader puzzled.\n\nThis is conclusion. I said \"file mode\" and \"file attributes\", which\nis how reason for ctime update is defined in SUSv3. man 2 stat says:\n\n       The field st_ctime is changed by writing or by setting  inode\n       information (i.e., owner, group, link count, mode, etc.).\n\nNot just \"inode\" but \"inode information\". Only mode is used, and even\nthat is ignored on Windows.\n"},{"id":"84789","messageId":"20080724190056.GA3677@blimp.local","threadId":"14569","inReplyTo":"7vr69lihkt.fsf@gitster.siamese.dyndns.org","subject":"[PATCH] Do not use ctime if file mode is not used","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-07-24T19:00:56Z","receivedAt":"2008-07-24T19:00:56Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On some file systems, the only part of inode information we need\n(executable) cannot be used, so ctime can be ignored as well. Change\ntime is updated when file attributes were changed (or it is written\nto, but in this case, mtime is updated as well).\n\nSigned-off-by: Alex Riesen <raa.lkml@gmail.com>\n---\n\nJunio C Hamano, Wed, Jul 23, 2008 02:12:50 +0200:\n> > I had that at first (NO_DEPENDABLE_CTIME, than IGNORE_CTIME), than\n> > deemed it excessive.\n> \n> Why is it excessive?  My initial reaction was \"what does trustable\n> filemode nor trust_executable_bit has anything to do with ctime\".  Please\n> explain.\n\nYou know, you have a good point... (and I'm sometimes really stupid)\nOf course it depends on the underlying filesystem!\n\nThe updated patch is untested yet, but should be obviously correct.\n\nBTW, any idea how to check if all callers of ce_match_stat_basic have\nread the configuration? It is not that essential to have\ntrust_executable_bit set correctly, though. In worst case an index\nentry will be marked not up-to-date.\n\n read-cache.c |    2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/read-cache.c b/read-cache.c\nindex a50a851..f2fa0d9 100644\n--- a/read-cache.c\n+++ b/read-cache.c\n@@ -181,7 +181,7 @@ static int ce_match_stat_basic(struct cache_entry *ce, struct stat *st)\n \t}\n \tif (ce->ce_mtime != (unsigned int) st->st_mtime)\n \t\tchanged |= MTIME_CHANGED;\n-\tif (ce->ce_ctime != (unsigned int) st->st_ctime)\n+\tif (trust_executable_bit && ce->ce_ctime != (unsigned int) st->st_ctime)\n \t\tchanged |= CTIME_CHANGED;\n \n \tif (ce->ce_uid != (unsigned int) st->st_uid ||\n-- \n1.6.0.rc0.70.g5aae9\n"},{"id":"84827","messageId":"alpine.LFD.1.10.0807241854580.5249@nehalem.linux-foundation.org","threadId":"14569","inReplyTo":"20080723191647.GF5283@blimp.local","subject":"Re: [PATCH] Build configuration to skip ctime for modification test","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-07-25T02:00:29Z","receivedAt":"2008-07-25T02:00:29Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 23 Jul 2008, Alex Riesen wrote:\n> \n> It is not that it is broken. We just don't need it, because the st_mode\n> is not used, and the rest of inode information is not used anyway.\n\nThat is NOT why git checks the ctime.\n\nGit checks the ctime not because it cares about the inode state being \nmodified per se: since it can see that _directly_ - so why should it care \nabout inode state like st_mode?\n\nNo, git checks ctime because it in general tries to make it VERY VERY hard \nfor people to try to \"fake out\" git and replace files from underneath it \nwithout git noticing.\n\nIt's much easier and much more common for tools to restore 'mtime' when \nthey do some operation on a file than it is for them to restore 'ctime'.\n\nFor example, if you rsync files between two hosts, the '-t' flag will make \nrsync try to keep the mtimes in sync (and it's part of '-a', which is the \ncommon form that you'd use for rsync). So if you only look at mtime and \nsize, you often miss the fact that the file has actually been messed with!\n\nLooking at ctime gets around a number of those things. Of course, it can \ncause git to be _too_ eager in thinking that a file is modified, and an \nexample of that is the insane indexing that 'beagle' does, which actually \nmodifies the files by adding inode extended attributes to them and thus \nchanges ctime due to the indexing. But in general it's a lot better to be \ntoo careful than to miss the fact that somebody changed the file.\n\n\t\tLinus\n"},{"id":"84925","messageId":"20080725055547.GA3699@blimp.local","threadId":"14569","inReplyTo":"alpine.LFD.1.10.0807241854580.5249@nehalem.linux-foundation.org","subject":"Re: [PATCH] Build configuration to skip ctime for modification test","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-07-25T05:55:47Z","receivedAt":"2008-07-25T05:55:47Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Linus Torvalds, Fri, Jul 25, 2008 04:00:29 +0200:\n> On Wed, 23 Jul 2008, Alex Riesen wrote:\n> > \n> > It is not that it is broken. We just don't need it, because the st_mode\n> > is not used, and the rest of inode information is not used anyway.\n> \n> That is NOT why git checks the ctime.\n> \n> Git checks the ctime not because it cares about the inode state being \n> modified per se: since it can see that _directly_ - so why should it care \n> about inode state like st_mode?\n> \n> No, git checks ctime because it in general tries to make it VERY VERY hard \n> for people to try to \"fake out\" git and replace files from underneath it \n> without git noticing.\n> \n> It's much easier and much more common for tools to restore 'mtime' when \n> they do some operation on a file than it is for them to restore 'ctime'.\n> \n> For example, if you rsync files between two hosts, the '-t' flag will make \n> rsync try to keep the mtimes in sync (and it's part of '-a', which is the \n> common form that you'd use for rsync). So if you only look at mtime and \n> size, you often miss the fact that the file has actually been messed with!\n> \n> Looking at ctime gets around a number of those things. Of course, it can \n> cause git to be _too_ eager in thinking that a file is modified, and an \n> example of that is the insane indexing that 'beagle' does, which actually \n> modifies the files by adding inode extended attributes to them and thus \n> changes ctime due to the indexing. But in general it's a lot better to be \n> too careful than to miss the fact that somebody changed the file.\n> \n\nBut, given the fact, that somewhere sometimes its very-very annoying\nto have even one (un)changed file, something must be done about it.\nMaybe just direct\n\n    # my .gitconfig for Windows machines with GDS\n    [core]\n\tfilemode = false\n\ttrustctime = false\n\tlogallrefupdates = false\n    [pack]\n\tthreads = 1\n\n    etc...\n"},{"id":"84975","messageId":"alpine.DEB.1.00.0807260256030.11976@eeepc-johanness","threadId":"14569","inReplyTo":"20080725055547.GA3699@blimp.local","subject":"Re: [PATCH] Build configuration to skip ctime for modification test","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-26T00:57:25Z","receivedAt":"2008-07-26T00:57:25Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 25 Jul 2008, Alex Riesen wrote:\n\n> But, given the fact, that somewhere sometimes its very-very annoying to \n> have even one (un)changed file, something must be done about it. Maybe \n> just direct\n> \n> [...]\n> \ttrustctime = false\n\n... which is all Junio and I were asking all along: a separate way to ask \nfor ignoring ctime; not just DWIM it on top of the executable bit.\n\nCiao,\nDscho\n"},{"id":"85161","messageId":"20080726153802.GA16868@blimp.local","threadId":"14569","inReplyTo":"alpine.DEB.1.00.0807260256030.11976@eeepc-johanness","subject":"[PATCH] Make use of stat.ctime configurable","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-07-26T15:38:02Z","receivedAt":"2008-07-26T15:38:02Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"because there are situations where it produces too much false\npositives. Like when file system crawlers keep changing it when\nscanning and using the ctime for marking scanned files.\n\nThe default is to allow use of ctime.\n\nSigned-off-by: Alex Riesen <raa.lkml@gmail.com>\n---\nJohannes Schindelin, Sat, Jul 26, 2008 02:57:25 +0200:\n> On Fri, 25 Jul 2008, Alex Riesen wrote:\n> > But, given the fact, that somewhere sometimes its very-very annoying to \n> > have even one (un)changed file, something must be done about it. Maybe \n> > just direct\n> > \n> > [...]\n> > \ttrustctime = false\n> \n> ... which is all Junio and I were asking all along: a separate way to ask \n> for ignoring ctime; not just DWIM it on top of the executable bit.\n\nOh...\n\n cache.h       |    1 +\n config.c      |    4 ++++\n environment.c |    1 +\n read-cache.c  |    2 +-\n 4 files changed, 7 insertions(+), 1 deletions(-)\n\ndiff --git a/cache.h b/cache.h\nindex 38985aa..00d02d3 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -421,6 +421,7 @@ extern int delete_ref(const char *, const unsigned char *sha1);\n \n /* Environment bits from configuration mechanism */\n extern int trust_executable_bit;\n+extern int trust_file_ctime;\n extern int quote_path_fully;\n extern int has_symlinks;\n extern int ignore_case;\ndiff --git a/config.c b/config.c\nindex 1e066c7..860e8ab 100644\n--- a/config.c\n+++ b/config.c\n@@ -341,6 +341,10 @@ static int git_default_core_config(const char *var, const char *value)\n \t\ttrust_executable_bit = git_config_bool(var, value);\n \t\treturn 0;\n \t}\n+\tif (!strcmp(var, \"core.filectime\")) {\n+\t\ttrust_file_ctime = git_config_bool(var, value);\n+\t\treturn 0;\n+\t}\n \n \tif (!strcmp(var, \"core.quotepath\")) {\n \t\tquote_path_fully = git_config_bool(var, value);\ndiff --git a/environment.c b/environment.c\nindex 4a88a17..4982771 100644\n--- a/environment.c\n+++ b/environment.c\n@@ -13,6 +13,7 @@ char git_default_email[MAX_GITNAME];\n char git_default_name[MAX_GITNAME];\n int user_ident_explicitly_given;\n int trust_executable_bit = 1;\n+int trust_file_ctime = 1;\n int has_symlinks = 1;\n int ignore_case;\n int assume_unchanged;\ndiff --git a/read-cache.c b/read-cache.c\nindex a50a851..00d39dc 100644\n--- a/read-cache.c\n+++ b/read-cache.c\n@@ -181,7 +181,7 @@ static int ce_match_stat_basic(struct cache_entry *ce, struct stat *st)\n \t}\n \tif (ce->ce_mtime != (unsigned int) st->st_mtime)\n \t\tchanged |= MTIME_CHANGED;\n-\tif (ce->ce_ctime != (unsigned int) st->st_ctime)\n+\tif (trust_file_ctime && ce->ce_ctime != (unsigned int) st->st_ctime)\n \t\tchanged |= CTIME_CHANGED;\n \n \tif (ce->ce_uid != (unsigned int) st->st_uid ||\n-- \n1.6.0.rc0.76.g581e\n"},{"id":"85194","messageId":"7v3alv156g.fsf@gitster.siamese.dyndns.org","threadId":"14569","inReplyTo":"20080726153802.GA16868@blimp.local","subject":"Re: [PATCH] Make use of stat.ctime configurable","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-27T19:46:15Z","receivedAt":"2008-07-27T19:46:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alex Riesen <raa.lkml@gmail.com> writes:\n\n> because there are situations where it produces too much false\n> positives. Like when file system crawlers keep changing it when\n> scanning and using the ctime for marking scanned files.\n\nThis justification is good and I am very inclined to advocate for its\ninclusion in 1.6.0, but any new configuration needs to be in the\ndocumentation.\n\nIt appears there is \"gui.trustmtime\"; shouldn't this be called\n\"core.trustctime\" or something?\n"},{"id":"85195","messageId":"7v1w1f155p.fsf@gitster.siamese.dyndns.org","threadId":"14569","inReplyTo":"20080726153802.GA16868@blimp.local","subject":"Re: [PATCH] Make use of stat.ctime configurable","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-27T19:46:42Z","receivedAt":"2008-07-27T19:46:42Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alex Riesen <raa.lkml@gmail.com> writes:\n\n> because there are situations where it produces too much false\n> positives. Like when file system crawlers keep changing it when\n> scanning and using the ctime for marking scanned files.\n\nThis justification is good and I am very inclined to advocate for its\ninclusion in 1.6.0, but any new configuration needs to be in the\ndocumentation.\n\nIt appears there is \"gui.trustmtime\"; shouldn't this be called\n\"core.trustctime\" or something?\n"},{"id":"85251","messageId":"20080728063128.GA4234@blimp.local","threadId":"14569","inReplyTo":"7v1w1f155p.fsf@gitster.siamese.dyndns.org","subject":"[PATCH] Make use of stat.ctime configurable","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-07-28T06:31:28Z","receivedAt":"2008-07-28T06:31:28Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"because there are situations where it produces too much false\npositives. Like when file system crawlers keep changing it when\nscanning and using the ctime for marking scanned files.\n\nThe default is to allow use of ctime.\n\nSigned-off-by: Alex Riesen <raa.lkml@gmail.com>\n---\nJunio C Hamano, Sun, Jul 27, 2008 21:46:42 +0200:\n> Alex Riesen <raa.lkml@gmail.com> writes:\n> \n> > because there are situations where it produces too much false\n> > positives. Like when file system crawlers keep changing it when\n> > scanning and using the ctime for marking scanned files.\n> \n> This justification is good and I am very inclined to advocate for its\n> inclusion in 1.6.0, but any new configuration needs to be in the\n> documentation.\n\nDone.\n\n> It appears there is \"gui.trustmtime\"; shouldn't this be called\n> \"core.trustctime\" or something?\n\nGetting old... I even called the global flag trust_file_ctime!\nCorrected. Changed trust_file_ctime to trust_ctime.\n\n Documentation/config.txt           |    7 +++++++\n Documentation/git-update-index.txt |    5 +++++\n cache.h                            |    1 +\n config.c                           |    4 ++++\n environment.c                      |    1 +\n read-cache.c                       |    2 +-\n 6 files changed, 19 insertions(+), 1 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 1a13abc..552c134 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -149,6 +149,13 @@ core.safecrlf::\n \t`core.autocrlf`, git will reject the file.  The variable can\n \tbe set to \"warn\", in which case git will only warn about an\n \tirreversible conversion but continue the operation.\n+\n+core.trustctime::\n+\tIf false, the ctime differences between the index and the\n+\tworking copy are ignored; useful when the inode change time\n+\tis regularly modified by something outside Git (file system\n+\tcrawlers and some backup systems).\n+\tSee linkgit:git-update-index[1]. True by default.\n +\n CRLF conversion bears a slight chance of corrupting data.\n autocrlf=true will convert CRLF to LF during commit and LF to\ndiff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt\nindex 6b930bc..1d9d81a 100644\n--- a/Documentation/git-update-index.txt\n+++ b/Documentation/git-update-index.txt\n@@ -323,6 +323,11 @@ from symbolic link to regular file.\n The command looks at `core.ignorestat` configuration variable.  See\n 'Using \"assume unchanged\" bit' section above.\n \n+The command also looks at `core.trustctime` configuration variable.\n+It can be useful when the inode change time is regularly modified by\n+something outside Git (file system crawlers and backup systems use\n+ctime for marking files processed) (see linkgit:git-config[1]).\n+\n \n SEE ALSO\n --------\ndiff --git a/cache.h b/cache.h\nindex 4b6c0a6..2475de9 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -423,6 +423,7 @@ extern int delete_ref(const char *, const unsigned char *sha1);\n \n /* Environment bits from configuration mechanism */\n extern int trust_executable_bit;\n+extern int trust_ctime;\n extern int quote_path_fully;\n extern int has_symlinks;\n extern int ignore_case;\ndiff --git a/config.c b/config.c\nindex 1e066c7..53f04a0 100644\n--- a/config.c\n+++ b/config.c\n@@ -341,6 +341,10 @@ static int git_default_core_config(const char *var, const char *value)\n \t\ttrust_executable_bit = git_config_bool(var, value);\n \t\treturn 0;\n \t}\n+\tif (!strcmp(var, \"core.trustctime\")) {\n+\t\ttrust_ctime = git_config_bool(var, value);\n+\t\treturn 0;\n+\t}\n \n \tif (!strcmp(var, \"core.quotepath\")) {\n \t\tquote_path_fully = git_config_bool(var, value);\ndiff --git a/environment.c b/environment.c\nindex 4a88a17..0c6d11f 100644\n--- a/environment.c\n+++ b/environment.c\n@@ -13,6 +13,7 @@ char git_default_email[MAX_GITNAME];\n char git_default_name[MAX_GITNAME];\n int user_ident_explicitly_given;\n int trust_executable_bit = 1;\n+int trust_ctime = 1;\n int has_symlinks = 1;\n int ignore_case;\n int assume_unchanged;\ndiff --git a/read-cache.c b/read-cache.c\nindex 6c08803..1cae361 100644\n--- a/read-cache.c\n+++ b/read-cache.c\n@@ -197,7 +197,7 @@ static int ce_match_stat_basic(struct cache_entry *ce, struct stat *st)\n \t}\n \tif (ce->ce_mtime != (unsigned int) st->st_mtime)\n \t\tchanged |= MTIME_CHANGED;\n-\tif (ce->ce_ctime != (unsigned int) st->st_ctime)\n+\tif (trust_ctime && ce->ce_ctime != (unsigned int) st->st_ctime)\n \t\tchanged |= CTIME_CHANGED;\n \n \tif (ce->ce_uid != (unsigned int) st->st_uid ||\n-- \n1.6.0.rc0.76.g581e\n"},{"id":"85301","messageId":"20080728160446.GA16351@old.davidb.org","threadId":"14569","inReplyTo":"20080728063128.GA4234@blimp.local","subject":"Re: [PATCH] Make use of stat.ctime configurable","fromName":"David Brown","fromEmail":"git@davidb.org","sentAt":"2008-07-28T16:04:46Z","receivedAt":"2008-07-28T16:04:46Z","isPatch":true,"sender":{"key":"git@davidb.org","avatar":"https://gravatar.com/avatar/94c86a2938470a74c2eac5e2b69afc0871f79a660295c02219597aba8cb101c1?d=mp&s=160"},"body":"On Mon, Jul 28, 2008 at 08:31:28AM +0200, Alex Riesen wrote:\n\n>because there are situations where it produces too much false\n>positives. Like when file system crawlers keep changing it when\n>scanning and using the ctime for marking scanned files.\n\nThat's interesting, since most backup software uses the ctime to determine\nfile changes.\n\nDavid\n"},{"id":"85302","messageId":"alpine.LFD.1.10.0807280906530.3486@nehalem.linux-foundation.org","threadId":"14569","inReplyTo":"20080728160446.GA16351@old.davidb.org","subject":"Re: [PATCH] Make use of stat.ctime configurable","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-07-28T16:09:32Z","receivedAt":"2008-07-28T16:09:32Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 28 Jul 2008, David Brown wrote:\n\n> On Mon, Jul 28, 2008 at 08:31:28AM +0200, Alex Riesen wrote:\n> \n> > because there are situations where it produces too much false\n> > positives. Like when file system crawlers keep changing it when\n> > scanning and using the ctime for marking scanned files.\n> \n> That's interesting, since most backup software uses the ctime to determine\n> file changes.\n\nIt really is just Beagle that is (was? I can dream) a piece of \nunbelievable crap.\n\nAnybody who uses extended attributes as part of a indexing scheme is just \ninsane. Modifying the file you are indexing is not just fundamentally \nwrong to begin with, but it will then also be incredibly inefficient to \nread those entries one at a time.\n\nAnd no other sane model would ever touch 'ctime'.\n\nOh, well. Making ctime configurable is not wrong per se. But if it's \nBeagle that triggers this, the fix is sadly in the wrong place.\n\n\t\tLinus\n"},{"id":"85304","messageId":"20080728162043.GG32184@machine.or.cz","threadId":"14569","inReplyTo":"20080728063128.GA4234@blimp.local","subject":"Re: [PATCH] Make use of stat.ctime configurable","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-07-28T16:20:43Z","receivedAt":"2008-07-28T16:20:43Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Mon, Jul 28, 2008 at 08:31:28AM +0200, Alex Riesen wrote:\n> diff --git a/Documentation/config.txt b/Documentation/config.txt\n> index 1a13abc..552c134 100644\n> --- a/Documentation/config.txt\n> +++ b/Documentation/config.txt\n> @@ -149,6 +149,13 @@ core.safecrlf::\n>  \t`core.autocrlf`, git will reject the file.  The variable can\n>  \tbe set to \"warn\", in which case git will only warn about an\n>  \tirreversible conversion but continue the operation.\n> +\n> +core.trustctime::\n> +\tIf false, the ctime differences between the index and the\n> +\tworking copy are ignored; useful when the inode change time\n> +\tis regularly modified by something outside Git (file system\n> +\tcrawlers and some backup systems).\n> +\tSee linkgit:git-update-index[1]. True by default.\n>  +\n>  CRLF conversion bears a slight chance of corrupting data.\n>  autocrlf=true will convert CRLF to LF during commit and LF to\n\nSomehow, this particular position of the new hunk does not feel like the\nbest choice. ;-)\n\n\t\t\t\tPetr \"Pasky\" Baudis\n"},{"id":"85421","messageId":"20080728214716.GB3721@blimp.local","threadId":"14569","inReplyTo":"20080728162043.GG32184@machine.or.cz","subject":"[PATCH] Improve the placement of core.trustctime in the documentation","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-07-28T21:47:16Z","receivedAt":"2008-07-28T21:47:16Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Accidentally, it split a _chapter_ about a file data corrup...\nconversion for a weird, but common operating system.\n\nSigned-off-by: Alex Riesen <raa.lkml@gmail.com>\n---\n\nPetr Baudis, Mon, Jul 28, 2008 18:20:43 +0200:\n> On Mon, Jul 28, 2008 at 08:31:28AM +0200, Alex Riesen wrote:\n> > diff --git a/Documentation/config.txt b/Documentation/config.txt\n> > index 1a13abc..552c134 100644\n> > --- a/Documentation/config.txt\n> > +++ b/Documentation/config.txt\n> > @@ -149,6 +149,13 @@ core.safecrlf::\n> >  \t`core.autocrlf`, git will reject the file.  The variable can\n> >  \tbe set to \"warn\", in which case git will only warn about an\n> >  \tirreversible conversion but continue the operation.\n> > +\n> > +core.trustctime::\n> > +\tIf false, the ctime differences between the index and the\n> > +\tworking copy are ignored; useful when the inode change time\n> > +\tis regularly modified by something outside Git (file system\n> > +\tcrawlers and some backup systems).\n> > +\tSee linkgit:git-update-index[1]. True by default.\n> >  +\n> >  CRLF conversion bears a slight chance of corrupting data.\n> >  autocrlf=true will convert CRLF to LF during commit and LF to\n> \n> Somehow, this particular position of the new hunk does not feel like the\n> best choice. ;-)\n> \n\nIt's alphabetical. Why? Oh, shit... Screw alphabetical\n\n Documentation/config.txt |   14 +++++++-------\n 1 files changed, 7 insertions(+), 7 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 552c134..61c3760 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -117,6 +117,13 @@ core.fileMode::\n \tthe working copy are ignored; useful on broken filesystems like FAT.\n \tSee linkgit:git-update-index[1]. True by default.\n \n+core.trustctime::\n+\tIf false, the ctime differences between the index and the\n+\tworking copy are ignored; useful when the inode change time\n+\tis regularly modified by something outside Git (file system\n+\tcrawlers and some backup systems).\n+\tSee linkgit:git-update-index[1]. True by default.\n+\n core.quotepath::\n \tThe commands that output paths (e.g. 'ls-files',\n \t'diff'), when not given the `-z` option, will quote\n@@ -149,13 +156,6 @@ core.safecrlf::\n \t`core.autocrlf`, git will reject the file.  The variable can\n \tbe set to \"warn\", in which case git will only warn about an\n \tirreversible conversion but continue the operation.\n-\n-core.trustctime::\n-\tIf false, the ctime differences between the index and the\n-\tworking copy are ignored; useful when the inode change time\n-\tis regularly modified by something outside Git (file system\n-\tcrawlers and some backup systems).\n-\tSee linkgit:git-update-index[1]. True by default.\n +\n CRLF conversion bears a slight chance of corrupting data.\n autocrlf=true will convert CRLF to LF during commit and LF to\n-- \n1.6.0.rc0.76.g581e\n"},{"id":"85422","messageId":"20080728214957.GC3721@blimp.local","threadId":"14569","inReplyTo":"alpine.LFD.1.10.0807280906530.3486@nehalem.linux-foundation.org","subject":"Re: [PATCH] Make use of stat.ctime configurable","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-07-28T21:49:57Z","receivedAt":"2008-07-28T21:49:57Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Linus Torvalds, Mon, Jul 28, 2008 18:09:32 +0200:\n> It really is just Beagle that is (was? I can dream) a piece of \n> unbelievable crap.\n> \n> Anybody who uses extended attributes as part of a indexing scheme is just \n> insane. Modifying the file you are indexing is not just fundamentally \n> wrong to begin with, but it will then also be incredibly inefficient to \n> read those entries one at a time.\n> \n> And no other sane model would ever touch 'ctime'.\n\nBeagle is not alone. Google Desktop Search was mentioned before.\n\n> Oh, well. Making ctime configurable is not wrong per se. But if it's \n> Beagle that triggers this, the fix is sadly in the wrong place.\n\nNever said it was a fix. Same as CRLF conversion is not a feature.\n"},{"id":"85376","messageId":"7vbq0ho5g7.fsf@gitster.siamese.dyndns.org","threadId":"14569","inReplyTo":"alpine.LFD.1.10.0807280906530.3486@nehalem.linux-foundation.org","subject":"Re: [PATCH] Make use of stat.ctime configurable","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-29T01:16:24Z","receivedAt":"2008-07-29T01:16:24Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@linux-foundation.org> writes:\n\n> On Mon, 28 Jul 2008, David Brown wrote:\n>\n>> On Mon, Jul 28, 2008 at 08:31:28AM +0200, Alex Riesen wrote:\n>> \n>> > because there are situations where it produces too much false\n>> > positives. Like when file system crawlers keep changing it when\n>> > scanning and using the ctime for marking scanned files.\n>> \n>> That's interesting, since most backup software uses the ctime to determine\n>> file changes.\n>\n> It really is just Beagle that is (was? I can dream) a piece of \n> unbelievable crap.\n>\n> Anybody who uses extended attributes as part of a indexing scheme is just \n> insane. Modifying the file you are indexing is not just fundamentally \n> wrong to begin with, but it will then also be incredibly inefficient to \n> read those entries one at a time.\n\nIt's a typo and you are saying it _is_ fundamentally wrong, aren't you?\n\nIf you are prepared to pick up new files, you need to crawl everywhere\nanyway, so if the xattr is used to leave a mark \"The last time I looked at\nthis file was this\" in the file itself, it does not sound too bad to me.\nIt would be irritating that it touches ctime, though, but I do not use it\nso it is not my problem ;-)\n\nhttp://beagle-project.org/FAQ \"Do I really need extended attributes?\"\ntalks about BEAGLE_DISABLE_XATTR environment variable and interestingly\nit says disabling use of xattr would slow you down.\n"},{"id":"85377","messageId":"alpine.LFD.1.10.0807281817230.3486@nehalem.linux-foundation.org","threadId":"14569","inReplyTo":"7vbq0ho5g7.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Make use of stat.ctime configurable","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-07-29T01:23:56Z","receivedAt":"2008-07-29T01:23:56Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 28 Jul 2008, Junio C Hamano wrote:\n> >\n> > Anybody who uses extended attributes as part of a indexing scheme is just \n> > insane. Modifying the file you are indexing is not just fundamentally \n> > wrong to begin with, but it will then also be incredibly inefficient to \n> > read those entries one at a time.\n> \n> It's a typo and you are saying it _is_ fundamentally wrong, aren't you?\n\nNot a typo, and I'm sayin that \"it's not _just_ fundamentally wrong\"\n\nSo yes, it's fundamentally wrong, but it's worse than that. It's \nfundamentally wrong _and_ it's inefficient as hell.\n\n> If you are prepared to pick up new files, you need to crawl everywhere\n> anyway, so if the xattr is used to leave a mark \"The last time I looked at\n> this file was this\" in the file itself, it does not sound too bad to me.\n\nIt's absolutely horrible. \n\nIt means that you have another extra indirection and accompanying disk \nseek to check the thing. It's a total performance nightmare. Trust me, \nanybody who uses extended attributes like this simply does not know what \nhe is doing.\n\n> It would be irritating that it touches ctime, though, but I do not use it\n> http://beagle-project.org/FAQ \"Do I really need extended attributes?\"\n> talks about BEAGLE_DISABLE_XATTR environment variable and interestingly\n> it says disabling use of xattr would slow you down.\n\nThey don't have a clue. They say that, but it's simply not true. \n\nOf course, the fact that they think it is probably implies that they did \nsomething EVEN MORE STUPID for the non-xattr case. That wouldn't surprise \nme at all. If I had to guess, I'd guess that they used an SQL database and \nquery language, and did all their tests with hot caches too.\n\nThe kernel does caching really well, and the kernel is fast as hell, so \n_of_course_ when you benchmark, using kernel data structures looks good, \nespecially if you benchmark against code that isn't well written for the \nparticular usage case.\n\n\t\t\tLinus\n"},{"id":"85378","messageId":"7v3alto4r7.fsf@gitster.siamese.dyndns.org","threadId":"14569","inReplyTo":"alpine.LFD.1.10.0807281817230.3486@nehalem.linux-foundation.org","subject":"Re: [PATCH] Make use of stat.ctime configurable","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-29T01:31:24Z","receivedAt":"2008-07-29T01:31:24Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@linux-foundation.org> writes:\n\n> The kernel does caching really well, and the kernel is fast as hell, so \n> _of_course_ when you benchmark, using kernel data structures looks good, \n> especially if you benchmark against code that isn't well written for the \n> particular usage case.\n\nOk.  While I have your attention on st_ctime, let me ask you a stupid\nquestion.  Why does \"rename(old, new)\" change st_ctime when you move a\nregular file?\n"},{"id":"85379","messageId":"20080729014120.GA26807@old.davidb.org","threadId":"14569","inReplyTo":"7v3alto4r7.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Make use of stat.ctime configurable","fromName":"David Brown","fromEmail":"git@davidb.org","sentAt":"2008-07-29T01:41:20Z","receivedAt":"2008-07-29T01:41:20Z","isPatch":true,"sender":{"key":"git@davidb.org","avatar":"https://gravatar.com/avatar/94c86a2938470a74c2eac5e2b69afc0871f79a660295c02219597aba8cb101c1?d=mp&s=160"},"body":"On Mon, Jul 28, 2008 at 06:31:24PM -0700, Junio C Hamano wrote:\n>Linus Torvalds <torvalds@linux-foundation.org> writes:\n>\n>> The kernel does caching really well, and the kernel is fast as hell, so \n>> _of_course_ when you benchmark, using kernel data structures looks good, \n>> especially if you benchmark against code that isn't well written for the \n>> particular usage case.\n>\n>Ok.  While I have your attention on st_ctime, let me ask you a stupid\n>question.  Why does \"rename(old, new)\" change st_ctime when you move a\n>regular file?\n\nA simple answer might be that posix requires it.  But, from the point of\nview of backup software, not updating the ctime on rename would be\nhorrible, because you'd never know when files got renamed.\n\nDavid\n"},{"id":"85381","messageId":"alpine.LFD.1.10.0807281853520.3486@nehalem.linux-foundation.org","threadId":"14569","inReplyTo":"7v3alto4r7.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Make use of stat.ctime configurable","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-07-29T01:55:47Z","receivedAt":"2008-07-29T01:55:47Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 28 Jul 2008, Junio C Hamano wrote:\n> \n> Ok.  While I have your attention on st_ctime, let me ask you a stupid\n> question.  Why does \"rename(old, new)\" change st_ctime when you move a\n> regular file?\n\nHmm. I think that's just a plain POSIX oddity. There's no real \"reason\" \nfor it, except the historical one: in really old UNIX terms, rename used \nto be a \"link+unlink\".\n\nAnd that \"link+unlink\" updated ctime because the 'nlink' part of the inode \nchanged. Never mind that it got changed right back ;)\n\n\t\t\tLinus\n"},{"id":"85383","messageId":"alpine.LFD.1.10.0807281857140.3486@nehalem.linux-foundation.org","threadId":"14569","inReplyTo":"alpine.LFD.1.10.0807281853520.3486@nehalem.linux-foundation.org","subject":"Re: [PATCH] Make use of stat.ctime configurable","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-07-29T02:01:40Z","receivedAt":"2008-07-29T02:01:40Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 28 Jul 2008, Linus Torvalds wrote:\n> \n> Hmm. I think that's just a plain POSIX oddity. There's no real \"reason\" \n> for it, except the historical one: in really old UNIX terms, rename used \n> to be a \"link+unlink\".\n\nSide note: a lot of the mtime/ctime/atime rules are really pretty \narbitrary. They've grown over time, and have various historic reasons.\n'ctime' in particular is more arbitrary than most, and I don't at all \nguarantee that all Unixes will work exactly the same wrt ctime and rename. \n\nIn fact, I -can- guarantee that some older versions of Linux haven't \nalways updated ctime on renames, for example, and it's probably still \nper-filesystem.\n\n\t\t\tLinus\n"},{"id":"85388","messageId":"7vy73lmmk6.fsf@gitster.siamese.dyndns.org","threadId":"14569","inReplyTo":"20080729014120.GA26807@old.davidb.org","subject":"Re: [PATCH] Make use of stat.ctime configurable","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-29T02:49:45Z","receivedAt":"2008-07-29T02:49:45Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Brown <git@davidb.org> writes:\n\n> On Mon, Jul 28, 2008 at 06:31:24PM -0700, Junio C Hamano wrote:\n>>Linus Torvalds <torvalds@linux-foundation.org> writes:\n>>\n>>> The kernel does caching really well, and the kernel is fast as\n>>> hell, so _of_course_ when you benchmark, using kernel data\n>>> structures looks good, especially if you benchmark against code\n>>> that isn't well written for the particular usage case.\n>>\n>>Ok.  While I have your attention on st_ctime, let me ask you a stupid\n>>question.  Why does \"rename(old, new)\" change st_ctime when you move a\n>>regular file?\n>\n> A simple answer might be that posix requires it.\n\nI would understand that an obvious implementation would be to link to new\nand then unlink the old, and the link count of the moved entity needs to\nchange (although in the end, the increment and decrement would cancel out)\nin each step, so it would be convenient for the implementation to update\nctime in both steps; however my reading of POSIX does not seem to require\nit.\n\nThe only mention of ctime I find is about updating the parent directories\nof old and new, as contents of both change so do their mtime and ctime\nobviously need to change.  But it does not talk about ctime of the entity\nbeing moved.\n\nAdditionally, the only way rename(2) is described to fail with EMLINK is\nwhen renaming an directory and the parent of the new location cannot have\nany more links; which implies that it does not have to fail if the first\nstep of link+unlink overflows the link count of old.\n\nAh, I found in the informative Application Usage section that this is\nimplementation dependent.\n\nSorry for the noise.\n"},{"id":"85424","messageId":"7vmyk1ky35.fsf@gitster.siamese.dyndns.org","threadId":"14569","inReplyTo":"20080728214716.GB3721@blimp.local","subject":"Re: [PATCH] Improve the placement of core.trustctime in the documentation","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-29T06:23:42Z","receivedAt":"2008-07-29T06:23:42Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alex Riesen <raa.lkml@gmail.com> writes:\n\n> Accidentally, it split a _chapter_ about a file data corrup...\n> conversion for a weird, but common operating system.\n>\n> Signed-off-by: Alex Riesen <raa.lkml@gmail.com>\n> ---\n>\n> Petr Baudis, Mon, Jul 28, 2008 18:20:43 +0200:\n>> On Mon, Jul 28, 2008 at 08:31:28AM +0200, Alex Riesen wrote:\n>> > diff --git a/Documentation/config.txt b/Documentation/config.txt\n>> > index 1a13abc..552c134 100644\n>> > --- a/Documentation/config.txt\n>> > +++ b/Documentation/config.txt\n>> > @@ -149,6 +149,13 @@ core.safecrlf::\n>> >  \t`core.autocrlf`, git will reject the file.  The variable can\n>> >  \tbe set to \"warn\", in which case git will only warn about an\n>> >  \tirreversible conversion but continue the operation.\n>> > +\n>> > +core.trustctime::\n>> > +\tIf false, the ctime differences between the index and the\n>> > +\tworking copy are ignored; useful when the inode change time\n>> > +\tis regularly modified by something outside Git (file system\n>> > +\tcrawlers and some backup systems).\n>> > +\tSee linkgit:git-update-index[1]. True by default.\n>> >  +\n>> >  CRLF conversion bears a slight chance of corrupting data.\n>> >  autocrlf=true will convert CRLF to LF during commit and LF to\n>> \n>> Somehow, this particular position of the new hunk does not feel like the\n>> best choice. ;-)\n>> \n>\n> It's alphabetical. Why? Oh, shit... Screw alphabetical\n\nYeah, I think it makes sense to put this after core.filemode.\n"},{"id":"85444","messageId":"alpine.DEB.1.00.0807291243260.4631@eeepc-johanness","threadId":"14569","inReplyTo":"20080729014120.GA26807@old.davidb.org","subject":"Re: [PATCH] Make use of stat.ctime configurable","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-29T10:45:00Z","receivedAt":"2008-07-29T10:45:00Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 28 Jul 2008, David Brown wrote:\n\n> On Mon, Jul 28, 2008 at 06:31:24PM -0700, Junio C Hamano wrote:\n>\n> > Why does \"rename(old, new)\" change st_ctime when you move a regular \n> >file?\n> \n> But, from the point of view of backup software, not updating the ctime \n> on rename would be horrible, because you'd never know when files got \n> renamed.\n\nAny backup software that does not discover that there is a new _filename_ \nis not worth the label \"software\".  Rather \"daftware\" or somesuch.\n\nCiao,\nDscho\n"},{"id":"85445","messageId":"alpine.DEB.1.00.0807291246270.4631@eeepc-johanness","threadId":"14569","inReplyTo":"alpine.LFD.1.10.0807281817230.3486@nehalem.linux-foundation.org","subject":"Re: [PATCH] Make use of stat.ctime configurable","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-29T10:49:54Z","receivedAt":"2008-07-29T10:49:54Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 28 Jul 2008, Linus Torvalds wrote:\n\n> On Mon, 28 Jul 2008, Junio C Hamano wrote:\n> > >\n> > > Anybody who uses extended attributes as part of a indexing scheme is \n> > > just insane. Modifying the file you are indexing is not just \n> > > fundamentally wrong to begin with, but it will then also be \n> > > incredibly inefficient to read those entries one at a time.\n> > \n> > It's a typo and you are saying it _is_ fundamentally wrong, aren't \n> > you?\n> \n> Not a typo, and I'm sayin that \"it's not _just_ fundamentally wrong\"\n> \n> So yes, it's fundamentally wrong, but it's worse than that. It's \n> fundamentally wrong _and_ it's inefficient as hell.\n\nI haven't looked at Beagle's source code either, but as a _user_ I can say \nthat it really became horribly, horribly slow after half a year of normal \nusage.\n\nAnd yes, uninstalling Beagle, backing up the files, reformatting and \nputting the files back (to really get rid of the extended attributes \nalready in the file system) helped.\n\nSo the first thing I did, back when I still used openSUSE, was to \nuninstall Beagle after the system install.\n\nCiao,\nDscho\n"}]}