Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Message-ID: <3B79D55F.9010300@ece.gatech.edu> Date: Tue, 14 Aug 2001 21:50:23 -0400 From: Charles Wilson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010713 X-Accept-Language: en-us MIME-Version: 1.0 To: cygwin AT Cygwin DOT Com CC: automake AT gnu DOT org, Bernard Dautrevaux , tim DOT van DOT holder AT pandora DOT be Subject: Re: Automake 1.4l released References: <3B7974C6 DOT 83934084 AT yahoo DOT com> <3B797B22 DOT C06C71D9 AT yahoo DOT com> <87bslip7hj DOT fsf AT creche DOT redhat DOT com> <20010814195923 DOT A28367 AT redhat DOT com> <87wv46uoac DOT fsf AT creche DOT redhat DOT com> <20010814211617 DOT C8849 AT redhat DOT com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Christopher Faylor wrote: > On Tue, Aug 14, 2001 at 07:04:11PM -0600, Tom Tromey wrote: > >>Chris> 3) Cygwin people provide workaround which is rejected. >> >>The original suggestion was "disable the feature". I'd prefer not to >>do that. Well, I guess so. I didn't really understand the feature; I did not realize (although I now understand) that changing the -r--r--r-- to -rw-r--r-- is equivalent to disabling the feature. >> > > I thought I saw another workaround which was rejected as being > too slow. Well, there were two. One was a suggestion for US (cygwin), which was to chmod +w ; do the timestamp thing ; chmod -w. I squashed that one because I thought it would slow down EVERY file access and dir listing on cygwin. As it happens, Corinna's suggested patch does exactly this -- but only inside the utime() function, AFAICT. THAT slows down only utime(), not everything else The other suggestion was to basically do ^^^^^^ within the automake script/generated Makefile.in's. I think that got squashed (by not-me) because of speed concerns, too. I think. >>Chris> AFAICT, the rationale for this stance is that Cygwin is a free >>Chris> software project and therefore we should just drop everything >>Chris> and fix "our bug" if we want automake to work. >> >>Please don't put words in my mouth. Of course I don't think you >>should drop anything for this problem. If it is a bug, which I don't >>even know for certain, then my preference would be that you prioritize >>it along with all the other things that you prioritize. >> >>Chris> Or, possibly, we're supposed to provide a detailed rationale on >>Chris> why it isn't possible to fix this in Windows. >> >>Or maybe you could choose not to care that `cp -p' doesn't work. Well, it does work. It preserves file attributes if possible -- even under cygwin. It's just that it (currently) is not possible to preserve those attributes on cygwin in all of the circumstances in which it IS possible to do so on linux. (got that?) Oh yeah -- and it cygwin's cp complains when it isn't possible to preserve attributes. linux's cp doesn't. Or at least that's the way it appears. > It actually doesn't work very well on non-NTFS filesystems. That's > known. We use what Microsoft provides us and we don't have much > to work with on anything besides NTFS. > > We could add code to cygwin which stored permissions in a separate > file on FAT "filesystems" but we've always been reluctant to add > that amount of overhead. U/WIN does this, though. All this, just so a maintainer-mode target works on cygwin+FAT? I hate to be a party pooper, but so what? Tom's right: cygwin hasn't been a popular *maintainer* platform yet -- and for those that WANT to use cygwin as a platform for autotool-based project maintainance, is it unreasonable to assume that NTFS+ntsec will be used? Perhaps the automake docs could mention that as a "requirement" on cygwin? *Assuming* we can get the behavior fixed. on cygwin/NTFS. which I think Corinna just did. > Basically, getting 'cp -p' to work on non-NTFS is a lot of work > and no one has shown any interest in doing it. This hasn't been > a big issue until now, AFAICR. As I said, I still don't think cygwin+automake+FAT+maintainer-mode is a big deal. Possibly not even nativeWin+automake+maintainer-mode (NTFS or FAT) -- but that's a decision for the automake folks. cygwin+automake+NTFS+maintainer-mode MAY be important; personally, I'd like to restrict the discussion to just that narrow interest. [snip rant about forced upgrades] > The fact is that cygwin is arguably broken *now*. It will be broken for > a few weeks at least. Not really. See my other message. > I'm not sure why there would be any hesitation to adding some sort of > workaround in automake. Isn't that what you would do with any broken > vendor OS? IMO, it is the only sane thing you can do if you don't want > to spend an annoying amount of time saying "Upgrade your > Cygwin/Solaris/Linux/Whatever." > > The other alternative is to document Cygwin's problem and hope that > enough people will read the documentation so that the bug report flow > won't be too high. we're talking about a pretty esoteric topic (using automake to maintain -- not merely build -- a project on cygwin). PLUS, even if you DO maintain a project using cygwin as your platform, only the distcheck target fails. I think the bug-report rate will probably be pretty low -- EVEN if no changes are made to EITHER cygwin OR automake. However, perhaps a note in the automake documentation about maintainer mode, cygwin, and requiring NTFS. (or did I already say that?) But first, I'd like to fix the problems with cygwin on NTFS! (But I *think* Corinna's utime() change does that...I'll test it in a while) >>If I made you angry, then I'm sorry. I have to say I'm surprised >>though. I thought I made my desire clear in my post. For instance, I >>said I would consider a workaround in automake as well as preferring >>that a real fix be made upstream, either in Cygwin or `cp' as >>appropriate. Maybe you prefer otherwise. >> > > I thought I made this same sentiment pretty clear, too. I think that > automake should include a work around, if possible, and I think that > Cygwin should be fixed, if possible. Ah...fix both! Not one or the other! > We are always interested in fixing UNIX compatibility bugs when they > don't involve excessive amount of kludging, and sometimes even then. > You can consider it a given that if we hear about a problem it is put on > our list of things to fix. The only time we fix the tools rather than > the DLL is when there seems to be no other way to solve the problem. Yeah...what he said. --Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/