{"thread":{"id":"44609","subject":"Git v2.11.0 breaks max depth nested alternates","startedAt":"2016-12-04T00:24:29Z","lastAt":"2016-12-05T12:09:17Z","messageCount":7,"participants":["Kyle J. McKay","Jeff King","Philip Oakley"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"306882","messageId":"fe33de5b5f0b3da68b249cc4a49a6d7@3c843fe6ba8f3c586a21345a2783aa0","threadId":"44609","inReplyTo":null,"subject":"Git v2.11.0 breaks max depth nested alternates","fromName":"Kyle J. McKay","fromEmail":"mackyle@gmail.com","sentAt":"2016-12-04T00:24:02Z","receivedAt":"2016-12-04T00:24:29Z","isPatch":false,"sender":{"key":"mackyle@gmail.com","avatar":"https://avatars.githubusercontent.com/u/813346?v=4"},"body":"The recent addition of pre-receive quarantining breaks nested  \nalternates that are already at the maximum alternates nesting depth.\n\nIn the file sha1_file.c in the function link_alt_odb_entries we have  \nthis:\n\n > if (depth > 5) {\n >         error(\"%s: ignoring alternate object stores, nesting too deep.\",\n >                         relative_base);\n >         return;\n > }\n\nWhen the incoming quarantine takes place the current objects directory  \nis demoted to an alternate thereby increasing its depth (and any  \nalternates it references) by one and causing any object store that was  \npreviously at the maximum nesting depth to be ignored courtesy of the  \nabove hard-coded maximum depth.\n\nIf the incoming push happens to need access to some of those objects  \nto perhaps \"--fix-thin\" its pack it will crash and burn.\n\nOriginally I was not going to include a patch to fix this, but simply  \nsuggest that the expeditious fix is to just allow one additional  \nalternates nesting depth level during quarantine operations.\n\nHowever, it was so simple, I have included the patch below :)\n\nI have verified that where a push with Git v2.10.2 succeeds and a push  \nwith Git v2.11.0 to the same repository fails because of this problem  \nthat the below patch does indeed correct the issue and allow the push  \nto succeed.\n\nCheers,\n\nKyle\n\n-- 8< --\nSubject: [PATCH] receive-pack: increase max alternates depth during quarantine\n\nEver since 722ff7f876 (receive-pack: quarantine objects until\npre-receive accepts, 2016-10-03, v2.11.0), Git has been quarantining\nobjects and packs received during an incoming push into a separate\nobjects directory and using the alternates mechanism to make them\navailable until they are either accepted and moved into the main\nobjects directory or rejected and discarded.\n\nUnfortunately this has the side effect of increasing the alternates\nnesting depth level by one for all pre-existing alternates.\n\nIf a repository is already at the maximum alternates nesting depth,\nthen this quarantining operation can temporarily push it over making\nthe incoming push fail.\n\nTo prevent the failure we simply increase the allowed alternates\nnesting depth by one whenever a quarantine operation is in effect.\n\nSigned-off-by: Kyle J. McKay <mackyle@gmail.com>\n---\n\nNotes:\n    Some alternates nesting depth background:\n    \n    If base/fork0/fork1/fork2/fork3/fork4/fork5 represents\n    seven git repositories where base.git has no alternates,\n    fork0.git has base.git as an alternate, fork1.git has\n    fork0.git as an alternate and so on where fork5.git has\n    only fork4.git as an alternate, then fork5.git is at\n    the maximum allowed depth of 5.  git fsck --strict --full\n    works without complaint on fork5.git.\n    \n    However, in base/fork0/fork1/fork2/fork3/fork4/fork5/fork6,\n    an fsck --strict --full of fork6.git will generate complaints\n    and any objects/packs present in base.git will be ignored.\n\n cache.h       | 1 +\n common-main.c | 3 +++\n environment.c | 1 +\n sha1_file.c   | 2 +-\n 4 files changed, 6 insertions(+), 1 deletion(-)\n\ndiff --git a/cache.h b/cache.h\nindex a50a61a1..25c17c29 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -676,6 +676,7 @@ extern size_t packed_git_limit;\n extern size_t delta_base_cache_limit;\n extern unsigned long big_file_threshold;\n extern unsigned long pack_size_limit_cfg;\n+extern int alt_odb_max_depth;\n \n /*\n  * Accessors for the core.sharedrepository config which lazy-load the value\ndiff --git a/common-main.c b/common-main.c\nindex c654f955..9f747491 100644\n--- a/common-main.c\n+++ b/common-main.c\n@@ -37,5 +37,8 @@ int main(int argc, const char **argv)\n \n \trestore_sigpipe_to_default();\n \n+\tif (getenv(GIT_QUARANTINE_ENVIRONMENT))\n+\t\talt_odb_max_depth++;\n+\n \treturn cmd_main(argc, argv);\n }\ndiff --git a/environment.c b/environment.c\nindex 0935ec69..32e11f70 100644\n--- a/environment.c\n+++ b/environment.c\n@@ -64,6 +64,7 @@ int merge_log_config = -1;\n int precomposed_unicode = -1; /* see probe_utf8_pathname_composition() */\n unsigned long pack_size_limit_cfg;\n enum hide_dotfiles_type hide_dotfiles = HIDE_DOTFILES_DOTGITONLY;\n+int alt_odb_max_depth = 5;\n \n #ifndef PROTECT_HFS_DEFAULT\n #define PROTECT_HFS_DEFAULT 0\ndiff --git a/sha1_file.c b/sha1_file.c\nindex 9c86d192..15b8432e 100644\n--- a/sha1_file.c\n+++ b/sha1_file.c\n@@ -337,7 +337,7 @@ static void link_alt_odb_entries(const char *alt, int len, int sep,\n \tint i;\n \tstruct strbuf objdirbuf = STRBUF_INIT;\n \n-\tif (depth > 5) {\n+\tif (depth > alt_odb_max_depth) {\n \t\terror(\"%s: ignoring alternate object stores, nesting too deep.\",\n \t\t\t\trelative_base);\n \t\treturn;\n---\n"},{"id":"306885","messageId":"20161204045554.advzvylytdmt2bh2@sigill.intra.peff.net","threadId":"44609","inReplyTo":"fe33de5b5f0b3da68b249cc4a49a6d7@3c843fe6ba8f3c586a21345a2783aa0","subject":"Re: Git v2.11.0 breaks max depth nested alternates","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-12-04T04:55:54Z","receivedAt":"2016-12-04T04:56:01Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Dec 03, 2016 at 04:24:02PM -0800, Kyle J. McKay wrote:\n\n> When the incoming quarantine takes place the current objects directory  \n> is demoted to an alternate thereby increasing its depth (and any  \n> alternates it references) by one and causing any object store that was  \n> previously at the maximum nesting depth to be ignored courtesy of the  \n> above hard-coded maximum depth.\n> \n> If the incoming push happens to need access to some of those objects  \n> to perhaps \"--fix-thin\" its pack it will crash and burn.\n\nYep, that makes sense. I didn't really worry about this because the\nexisting \"5\" is totally arbitrary, and meant to be so high that nobody\nreaches it (it's just there to break cycles).\n\nSo I do think this is worth dealing with, but I'm also curious why\nyou're hitting the depth-5 limit. I'm guessing it has to do with hosting\na hierarchy of related repos. But is your system then always in danger\nof busting the 5-limit if people create too deep a repository hierarchy?\n\nSpecifically, I'm wondering if it would be sufficient to just bump it to\n6. Or 100.\n\nOf course any static bump runs into the funny case where a repo\n_usually_ works, but fails when pushed to. Which is kind of nasty and\nunintuitive. And your patch fixes that, and we can leave the idea of\nbumping the static depth number as an orthogonal issue (that personally,\nI do not care about much about either way).\n\n> diff --git a/common-main.c b/common-main.c\n> index c654f955..9f747491 100644\n> --- a/common-main.c\n> +++ b/common-main.c\n> @@ -37,5 +37,8 @@ int main(int argc, const char **argv)\n>  \n>  \trestore_sigpipe_to_default();\n>  \n> +\tif (getenv(GIT_QUARANTINE_ENVIRONMENT))\n> +\t\talt_odb_max_depth++;\n> +\n>  \treturn cmd_main(argc, argv);\n\nAfter reading your problem description, my initial thought was to\nincrement the counter when we allocate the tmp-objdir, and decrement\nwhen it is destroyed. Because the parent receive-pack process adds it to\nits alternates, too. But:\n\n  1. Receive-pack doesn't care; it adds the tmp-objdir as an alternate,\n     rather than adding it as its main object dir and bumping down the\n     main one.\n\n  2. There would have to be some way of communicating to sub-processes\n     that they should bump their max-depth by one.\n\nYou've basically used the quarantine-path variable as the\ninter-process flag for (2). Which feels a little funny, because its\nvalue is unrelated to the alt-odb setup. But it is a reliable signal, so\nthere's a certain elegance. It's probably the best option, given that\nthe alternative is a specific variable to say \"hey, bump your\nmax-alt-odb-depth by one\". That's pretty ugly, too. :)\n\n-Peff\n"},{"id":"306888","messageId":"E3C2AF2A-FE07-4C94-B549-3BDAF9B3DB5D@gmail.com","threadId":"44609","inReplyTo":"20161204045554.advzvylytdmt2bh2@sigill.intra.peff.net","subject":"Re: Git v2.11.0 breaks max depth nested alternates","fromName":"Kyle J. McKay","fromEmail":"mackyle@gmail.com","sentAt":"2016-12-04T09:37:00Z","receivedAt":"2016-12-04T09:37:08Z","isPatch":false,"sender":{"key":"mackyle@gmail.com","avatar":"https://avatars.githubusercontent.com/u/813346?v=4"},"body":"On Dec 3, 2016, at 20:55, Jeff King wrote:\n\n> So I do think this is worth dealing with, but I'm also curious why\n> you're hitting the depth-5 limit. I'm guessing it has to do with  \n> hosting\n> a hierarchy of related repos. But is your system then always in danger\n> of busting the 5-limit if people create too deep a repository  \n> hierarchy?\n\nNo we check for the limit.  Anything at the limit gets broken by the  \nquarantine change though.\n\n> Specifically, I'm wondering if it would be sufficient to just bump  \n> it to\n> 6. Or 100.\n\nWell, if we left the current limit in place, but as you say:\n\n> Of course any static bump runs into the funny case where a repo\n> _usually_ works, but fails when pushed to. Which is kind of nasty and\n> unintuitive. And your patch fixes that,\n\nYes.  That's not nice, hence the patch.  Without the fix, pushing  \nmight work sometimes until you actually need to access cut-off objects  \nat pre-receive time.  So you might be able to push sometimes and  \nsometimes it breaks.\n\n> and we can leave the idea of\n> bumping the static depth number as an orthogonal issue (that  \n> personally,\n> I do not care about much about either way).\n\nThe patch is a step on that road.  It doesn't go that far but all it  \nwould take is connecting the introduced variable to a config item.   \nBut you still need to bump it by 1 during quarantine operations.  Such  \nsupport would even allow alternates to be disallowed (except during  \nquarantine).  I wonder if there's an opportunity for further pack  \noperation optimizations in such a case (you know there are no  \nalternates because they're not allowed)?\n\n>> diff --git a/common-main.c b/common-main.c\n>> index c654f955..9f747491 100644\n>> --- a/common-main.c\n>> +++ b/common-main.c\n>> @@ -37,5 +37,8 @@ int main(int argc, const char **argv)\n>>\n>> \trestore_sigpipe_to_default();\n>>\n>> +\tif (getenv(GIT_QUARANTINE_ENVIRONMENT))\n>> +\t\talt_odb_max_depth++;\n>> +\n>> \treturn cmd_main(argc, argv);\n>\n> After reading your problem description, my initial thought was to\n> increment the counter when we allocate the tmp-objdir, and decrement\n> when it is destroyed. Because the parent receive-pack process adds  \n> it to\n> its alternates, too. But:\n>\n>  1. Receive-pack doesn't care; it adds the tmp-objdir as an alternate,\n>     rather than adding it as its main object dir and bumping down the\n>     main one.\n>\n>  2. There would have to be some way of communicating to sub-processes\n>     that they should bump their max-depth by one.\n\nAll true.  And I had similar thoughts.  Perhaps we should add your  \ncomments to the patch description?  There seems to be a trend towards  \nhaving longer patch descriptions these days... ;)\n\n> You've basically used the quarantine-path variable as the\n> inter-process flag for (2). Which feels a little funny, because its\n> value is unrelated to the alt-odb setup. But it is a reliable  \n> signal, so\n> there's a certain elegance. It's probably the best option, given that\n> the alternative is a specific variable to say \"hey, bump your\n> max-alt-odb-depth by one\". That's pretty ugly, too. :)\n\nYou took the words right out of my mouth...   I guess I need to work  \non doing a better job of dumping my stream-of-thoughts that go into a  \npatch into the emails to the list.\n\nMost all of your comments could be dumped into the patch description  \nas-is to pimp it out some.  I have no objection to that, even adding  \nan \"Additional-analysis-by:\" (or similar) credit line too.  :)\n\n--Kyle\n"},{"id":"306890","messageId":"49DE271A91214D6DADBD4DE667A1659B@PhilipOakley","threadId":"44609","inReplyTo":"fe33de5b5f0b3da68b249cc4a49a6d7@3c843fe6ba8f3c586a21345a2783aa0","subject":"Re: Git v2.11.0 breaks max depth nested alternates","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":null,"receivedAt":"2016-12-04T11:23:02Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Kyle J. McKay\" <mackyle@gmail.com>\nSent: Sunday, December 04, 2016 12:24 AM\n> The recent addition of pre-receive quarantining breaks nested\n> alternates that are already at the maximum alternates nesting depth.\n>\n> In the file sha1_file.c in the function link_alt_odb_entries we have\n> this:\n>\n> > if (depth > 5) {\n> >         error(\"%s: ignoring alternate object stores, nesting too deep.\",\n> >                         relative_base);\n> >         return;\n> > }\n>\n> When the incoming quarantine takes place the current objects directory\n> is demoted to an alternate thereby increasing its depth (and any\n> alternates it references) by one and causing any object store that was\n> previously at the maximum nesting depth to be ignored courtesy of the\n> above hard-coded maximum depth.\n>\n> If the incoming push happens to need access to some of those objects\n> to perhaps \"--fix-thin\" its pack it will crash and burn.\n>\n> Originally I was not going to include a patch to fix this, but simply\n> suggest that the expeditious fix is to just allow one additional\n> alternates nesting depth level during quarantine operations.\n>\n> However, it was so simple, I have included the patch below :)\n>\n> I have verified that where a push with Git v2.10.2 succeeds and a push\n> with Git v2.11.0 to the same repository fails because of this problem\n> that the below patch does indeed correct the issue and allow the push\n> to succeed.\n>\n> Cheers,\n>\n> Kyle\n>\n> -- 8< --\n> Subject: [PATCH] receive-pack: increase max alternates depth during \n> quarantine\n>\n> Ever since 722ff7f876 (receive-pack: quarantine objects until\n> pre-receive accepts, 2016-10-03, v2.11.0), Git has been quarantining\n> objects and packs received during an incoming push into a separate\n> objects directory and using the alternates mechanism to make them\n> available until they are either accepted and moved into the main\n> objects directory or rejected and discarded.\n\nIs there a step here that after the accepted/rejected stage, it should then \ndecrement the limit back to its original value. The problem description \nsuggests that might be the case.\n--\nPhilip\n\n>\n> Unfortunately this has the side effect of increasing the alternates\n> nesting depth level by one for all pre-existing alternates.\n>\n> If a repository is already at the maximum alternates nesting depth,\n> then this quarantining operation can temporarily push it over making\n> the incoming push fail.\n>\n> To prevent the failure we simply increase the allowed alternates\n> nesting depth by one whenever a quarantine operation is in effect.\n>\n> Signed-off-by: Kyle J. McKay <mackyle@gmail.com>\n> ---\n>\n> Notes:\n>    Some alternates nesting depth background:\n>\n>    If base/fork0/fork1/fork2/fork3/fork4/fork5 represents\n>    seven git repositories where base.git has no alternates,\n>    fork0.git has base.git as an alternate, fork1.git has\n>    fork0.git as an alternate and so on where fork5.git has\n>    only fork4.git as an alternate, then fork5.git is at\n>    the maximum allowed depth of 5.  git fsck --strict --full\n>    works without complaint on fork5.git.\n>\n>    However, in base/fork0/fork1/fork2/fork3/fork4/fork5/fork6,\n>    an fsck --strict --full of fork6.git will generate complaints\n>    and any objects/packs present in base.git will be ignored.\n>\n> cache.h       | 1 +\n> common-main.c | 3 +++\n> environment.c | 1 +\n> sha1_file.c   | 2 +-\n> 4 files changed, 6 insertions(+), 1 deletion(-)\n>\n> diff --git a/cache.h b/cache.h\n> index a50a61a1..25c17c29 100644\n> --- a/cache.h\n> +++ b/cache.h\n> @@ -676,6 +676,7 @@ extern size_t packed_git_limit;\n> extern size_t delta_base_cache_limit;\n> extern unsigned long big_file_threshold;\n> extern unsigned long pack_size_limit_cfg;\n> +extern int alt_odb_max_depth;\n>\n> /*\n>  * Accessors for the core.sharedrepository config which lazy-load the \n> value\n> diff --git a/common-main.c b/common-main.c\n> index c654f955..9f747491 100644\n> --- a/common-main.c\n> +++ b/common-main.c\n> @@ -37,5 +37,8 @@ int main(int argc, const char **argv)\n>\n>  restore_sigpipe_to_default();\n>\n> + if (getenv(GIT_QUARANTINE_ENVIRONMENT))\n> + alt_odb_max_depth++;\n> +\n>  return cmd_main(argc, argv);\n> }\n> diff --git a/environment.c b/environment.c\n> index 0935ec69..32e11f70 100644\n> --- a/environment.c\n> +++ b/environment.c\n> @@ -64,6 +64,7 @@ int merge_log_config = -1;\n> int precomposed_unicode = -1; /* see probe_utf8_pathname_composition() */\n> unsigned long pack_size_limit_cfg;\n> enum hide_dotfiles_type hide_dotfiles = HIDE_DOTFILES_DOTGITONLY;\n> +int alt_odb_max_depth = 5;\n>\n> #ifndef PROTECT_HFS_DEFAULT\n> #define PROTECT_HFS_DEFAULT 0\n> diff --git a/sha1_file.c b/sha1_file.c\n> index 9c86d192..15b8432e 100644\n> --- a/sha1_file.c\n> +++ b/sha1_file.c\n> @@ -337,7 +337,7 @@ static void link_alt_odb_entries(const char *alt, int \n> len, int sep,\n>  int i;\n>  struct strbuf objdirbuf = STRBUF_INIT;\n>\n> - if (depth > 5) {\n> + if (depth > alt_odb_max_depth) {\n>  error(\"%s: ignoring alternate object stores, nesting too deep.\",\n>  relative_base);\n>  return;\n> ---\n> \n\n"},{"id":"306915","messageId":"20161205071431.cf3oy7nceyb7hggw@sigill.intra.peff.net","threadId":"44609","inReplyTo":"E3C2AF2A-FE07-4C94-B549-3BDAF9B3DB5D@gmail.com","subject":"Re: Git v2.11.0 breaks max depth nested alternates","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-12-05T07:14:31Z","receivedAt":"2016-12-05T07:14:38Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Dec 04, 2016 at 01:37:00AM -0800, Kyle J. McKay wrote:\n\n> On Dec 3, 2016, at 20:55, Jeff King wrote:\n> \n> > So I do think this is worth dealing with, but I'm also curious why\n> > you're hitting the depth-5 limit. I'm guessing it has to do with hosting\n> > a hierarchy of related repos. But is your system then always in danger\n> > of busting the 5-limit if people create too deep a repository hierarchy?\n> \n> No we check for the limit.  Anything at the limit gets broken by the\n> quarantine change though.\n\nOK. So the limit is an issue for your system, but one that you're able\nto deal gracefully with (and the quarantine change makes that a lot\nharder). I buy that line of reasoning.\n\n> The patch is a step on that road.  It doesn't go that far but all it would\n> take is connecting the introduced variable to a config item.  But you still\n> need to bump it by 1 during quarantine operations.  Such support would even\n> allow alternates to be disallowed (except during quarantine).  I wonder if\n> there's an opportunity for further pack operation optimizations in such a\n> case (you know there are no alternates because they're not allowed)?\n\nI doubt it. We look at the list of alternates early on, and in most\ncases there aren't any. So any optimization there can be done already at\nthat point.\n\nThe only optimization I know if in that area is 56dfeb626 (pack-objects:\ncompute local/ignore_pack_keep early, 2016-07-29), which works already.\n\n> All true.  And I had similar thoughts.  Perhaps we should add your comments\n> to the patch description?  There seems to be a trend towards having longer\n> patch descriptions these days... ;)\n\nFeel free to pick out anything that's useful and add it in verbatim or\nrephrased, whichever is more convenient.\n\n> You took the words right out of my mouth...   I guess I need to work on\n> doing a better job of dumping my stream-of-thoughts that go into a patch\n> into the emails to the list.\n\nIt's a lot easier when you're the reviewer, because you don't start\nreading through the commit-message with a full understanding of the\nproblem yet. :)\n\n> Most all of your comments could be dumped into the patch description as-is\n> to pimp it out some.  I have no objection to that, even adding an\n> \"Additional-analysis-by:\" (or similar) credit line too.  :)\n\nSure. I don't really need credit, or even just \"reviewed-by\" is fine.\nTalking and generating a shared understanding of the problem is part of\nthe review process.\n\n-Peff\n"},{"id":"306916","messageId":"20161205071822.ndeswelgj5epej5k@sigill.intra.peff.net","threadId":"44609","inReplyTo":"49DE271A91214D6DADBD4DE667A1659B@PhilipOakley","subject":"Re: Git v2.11.0 breaks max depth nested alternates","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-12-05T07:18:22Z","receivedAt":"2016-12-05T07:18:28Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Dec 04, 2016 at 11:22:52AM -0000, Philip Oakley wrote:\n\n> > Ever since 722ff7f876 (receive-pack: quarantine objects until\n> > pre-receive accepts, 2016-10-03, v2.11.0), Git has been quarantining\n> > objects and packs received during an incoming push into a separate\n> > objects directory and using the alternates mechanism to make them\n> > available until they are either accepted and moved into the main\n> > objects directory or rejected and discarded.\n> \n> Is there a step here that after the accepted/rejected stage, it should then\n> decrement the limit back to its original value. The problem description\n> suggests that might be the case.\n\nNo. I thought that at first, too, but this increment happens in the\nsub-process which is using the extra level of alternates for its entire\nlifetime. So it \"resets\" it by exiting, and the parent process never\nincrements its internal value at all.\n\n-Peff\n"},{"id":"306931","messageId":"4F8F730766044D0DB6CF89DDC579F36D@PhilipOakley","threadId":"44609","inReplyTo":"20161205071822.ndeswelgj5epej5k@sigill.intra.peff.net","subject":"Re: Git v2.11.0 breaks max depth nested alternates","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":null,"receivedAt":"2016-12-05T12:09:17Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Jeff King\" <peff@peff.net>\n> On Sun, Dec 04, 2016 at 11:22:52AM -0000, Philip Oakley wrote:\n>\n>> > Ever since 722ff7f876 (receive-pack: quarantine objects until\n>> > pre-receive accepts, 2016-10-03, v2.11.0), Git has been quarantining\n>> > objects and packs received during an incoming push into a separate\n>> > objects directory and using the alternates mechanism to make them\n>> > available until they are either accepted and moved into the main\n>> > objects directory or rejected and discarded.\n>>\n>> Is there a step here that after the accepted/rejected stage, it should \n>> then\n>> decrement the limit back to its original value. The problem description\n>> suggests that might be the case.\n>\n> No. I thought that at first, too, but this increment happens in the\n> sub-process which is using the extra level of alternates for its entire\n> lifetime. So it \"resets\" it by exiting, and the parent process never\n> increments its internal value at all.\n>\nThanks for the clarification.\n--\nPhilip \n\n"}]}