X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=0.6 required=5.0	tests=AWL,BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD
X-Spam-Check-By: sourceware.org
To: cygwin AT cygwin DOT com
From: Heinz Werner Kramski <Heinz DOT Werner DOT Kramski AT dla-marbach DOT de>
Subject: Re: 1.7: Basic file operations fail on network shares provided by Tru64 Advanced Server
Date: Wed, 25 Aug 2010 08:55:32 +0200
Lines: 70
Message-ID: <i52ep5$7f4$1@dough.gmane.org>
References: <4C73712F DOT 7000801 AT dla-marbach DOT de> <20100824083631 DOT GN6726 AT calimero DOT vinschen DOT de> <i5042b$fln$1 AT dough DOT gmane DOT org> <20100824122144 DOT GS6726 AT calimero DOT vinschen DOT de> <i50qpr$k60$1 AT dough DOT gmane DOT org> <20100824162810 DOT GU6726 AT calimero DOT vinschen DOT de>
Reply-To: Heinz DOT Werner DOT Kramski AT dla-marbach DOT de
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2
In-Reply-To: <20100824162810.GU6726@calimero.vinschen.de>
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Am 24.08.2010 18:28, schrieb Corinna Vinschen:
>> RCS now works again (also in Windows Emacs), and so does a ~ 1300
>> lines script I'm currently working on. Is it safe to use this
>> cygwin1-test2.dll for serious work? We are just preparing a new
>> master image for several PCs and would like to include a working
>> Cygwin 1.7.
>
> Please wait.  I was hoping that you could test a little bit further.

Sure.

> I prepared another DLL, which is very close to the "real" thing.
> There's another flag which I have to know if it's required or not.
>
>    http://cygwin.de/cygwin-ug-177/cygwin1-test4.dll.bz2
>    (md5sum 889a86df2c2aafd010249b27bf10f411)
>
> If it works, we're finished.  If not, we probably need just one more
> iteration.

Test4 works, great.

>
> In the meantime, can you send the output of `mount' to this list?
> I would like to make sure that the drives are really recognized as
> "cifs".

Testing was done in /mnt/testperms with the following mounts in effect:

     $ mount
     //dlanserv/kramski$ on /mnt type cifs (binary,notexec,ihash,user)
     C:/cygwin/bin on /usr/bin type ntfs (binary,auto)
     C:/cygwin/lib on /usr/lib type ntfs (binary,auto)
     C:/cygwin on / type ntfs (binary,auto)
     C:/bin32 on /usr/local/bin type ntfs (binary)
     C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
     D: on /cygdrive/d type ntfs (binary,posix=0,user,noumount,auto)
     E: on /cygdrive/e type cifs (binary,posix=0,user,noumount,auto)
     F: on /cygdrive/f type cifs (binary,posix=0,user,noumount,auto)
     G: on /cygdrive/g type cifs (binary,posix=0,user,noumount,auto)
     H: on /cygdrive/h type cifs (binary,posix=0,user,noumount,auto)
     I: on /cygdrive/i type cifs (binary,posix=0,user,noumount,auto)
     J: on /cygdrive/j type cifs (binary,posix=0,user,noumount,auto)
     O: on /cygdrive/o type cifs (binary,posix=0,user,noumount,auto)
     P: on /cygdrive/p type cifs (binary,posix=0,user,noumount,auto)
     R: on /cygdrive/r type cifs (binary,posix=0,user,noumount,auto)
     S: on /cygdrive/s type cifs (binary,posix=0,user,noumount,auto)
     T: on /cygdrive/t type cifs (binary,posix=0,user,noumount,auto)
     W: on /cygdrive/w type cifs (binary,posix=0,user,noumount,auto)
     X: on /cygdrive/x type cifs (binary,posix=0,user,noumount,auto)
     Y: on /cygdrive/y type cifs (binary,posix=0,user,noumount,auto)

> As for the ihash issue, after giving this some thought I tend to keep it
> as it is, so you will have to use it on your Tru64 drives.  At least for
> the next Cygwin release 1.7.7.  If it's getting too awkward at some
> point, we can discuss this again.

As you see, I have quite a lot of network drives, so I'm considering 
putting the ihash option globally to the uncommented /cygdrive 
mountpoint in /etc/fstab to cure all drives altogether. Will that cause 
any disadvantages for the real hardware NTFS drives C: and D:? (Doesn't 
look so at a first glance.)

Please note the nice effect that ihashing /cygdrive/e also cures 
//dlanserv/KRAMSKI$, my Cygwin $HOME, which - apart from this testing - 
is not explicitly listed by mount. (My home share //dlanserv/KRAMSKI$ is 
mapped to E: on Windows).

Regards,
    Heinz


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple