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 From: M4um AT aol DOT com Message-ID: Date: Wed, 3 Jan 2001 21:31:57 EST Subject: Re: #includes not being processed across network (revised) To: cygwin AT cygwin DOT com CC: earnie_boyd AT yahoo DOT com (Earnie Boyd), lhall AT rfk DOT com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 4.0 for Windows 95 sub 109 Earnie: >No one else has your environment. You will have to > debug this yourself, but we'll try to help with suggestions. Thanks, in advance, for any help you can offer. > Can other programs read the files? E.G.: `cat /UNIX/foo.h' gives what > results? Cat, less, vi, etc. all work as expected, even in parallel (simultaneous multiple accesses) under bash, "raw" sh and/or DOS commands ("type", etc). > Could it be a timing issue, or a permissions issue? Since I can access and modify files using both bash and "raw" sh, permissions would seem to be OK. Locking appears to work properly, also. Refering to cygcheck (previous email): the system understands me to be "root", a super-user. As far as "timing" goes, I've noticed on several occasions that there seems to be some file-timing anomalies within Cygwin. For example, in a script (batch file) that has a number of steps, each ending in "> _log" in order to trace execution, I often lose part of the trace -- it appears as if the next step produces output into _log before the preceding step has flushed its contents into _log and closed the file. It seems reasonable that this anomaly -- if it really exists -- would be more likely to occur when working across a network because of the inherent hardware/software delay. Remember that, in the #include problem I'm having, the #included file is being found by the cpp, but it is not being processed -- and there is no error message being generated. This lack of message ("cannot access", "not found", "locked", etc.) would seem to suggest something out of the ordinary. > Are you using Cygwin > symlinks on your H: directory, that most likely won't work unless you > can emulate > the Win32 system file bit on your UNIX server. No, until I get this straightened out I will differ from using any "soft links", DOS shortcuts or other redirections that might complicate the issue. Any tests you can suggest that might help me isolate the problem? Thanks, John -- Want to unsubscribe from this list? Check out: http://cygwin.com/ml/#unsubscribe-simple