Date: Sun, 13 May 2001 16:07:54 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Richard Dawe cc: djgpp-workers AT delorie DOT com Subject: Re: ANNOUNCE: Fileutils 4.0 beta 2 In-Reply-To: <3AFE8350.71B1B4F1@phekda.freeserve.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Sun, 13 May 2001, Richard Dawe wrote: > Up to this point I have been describing the beta that you tested with - > beta 2. Thanks; I will need to read this carefully looking at the code, to recall all the details. For now, a few short comments. > > I'm not sure this is the best plan. The files in lib/ are used by other > > GNU packages, so any changes to them might break something else. > > I agree - I realise lib/ is used also by Textutils. Are there any other > packages - Shellutils perhaps? All of the above, and, hopefull, even GNU Tar (if Paul Eggert, the current Tar maintainer, ever gets to integrating my changes). The version you see in Fileutils was originally written for Tar, and it actually works in the latest Tar port. > I can see two problems with the fixes for DJGPP: > > * It does not save and restore the current user and group in the > environment. This could cause unexpected side-effects. Could you spell out some of these side effects? > * It makes all user & group names map to the same uid & gid respectively. > This may be what you want in some cases. But there is no way to > distinguish between current user & group and every other user & group. In > chown and chgrp you want the second behaviour. I don't think I see why the value of uid and gid matter. > Eli, in the 3.16 port you added a change (for MSDOS) to set uid and gid to > 2*getuid() or 2*getgid() respectively, when the user and group name > lookups failed. That was a quick-and-dirty hack. It allowed Fileutils to work reasonably well, but required quite a few changes to the application's code. I never liked that solution; I think the one in userspec.c is better. If this gets too complicated to fix in userspec.c, perhaps we should consider fixing it in libc.a.