From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 392 invoked by alias); 11 May 2012 16:22:30 -0000 Received: (qmail 32749 invoked by uid 22791); 11 May 2012 16:21:51 -0000 X-Spam-Check-By: sourceware.org Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.83/v0.83-20-g38e4449) with ESMTP; Fri, 11 May 2012 16:21:36 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id 124472C14F1; Fri, 11 May 2012 18:21:34 +0200 (CEST) Date: Fri, 11 May 2012 16:22:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: CYGWIN inode over Samba share not constructed from IndexNumber Message-ID: <20120511162134.GJ13090@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <6.2.5.6.2.20120511114149.05c9f560@flumedata.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20120511114149.05c9f560@flumedata.com> User-Agent: Mutt/1.5.21 (2010-09-15) Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2012-05/txt/msg00237.txt.bz2 On May 11 11:42, starlight.2012q2@binnacle.cx wrote: > Hello, > > Ran into a quirk that caused some trouble. > > For some reason CYGWIN 1.7.5 (I know this is old) You should really update. > is constructing inode values for files on > Samba (3.6.4) shares with a different algorithm > than is used for files on NTFS volumes. > > This caused a script that checks for matching > hard-links to fail. > > Confirmed that Samba is returning the actual > inode values in 'IndexNumber' with 'procmon' > while running the > > stat -c '%h %d %i' filename > > command. See https://lists.samba.org/archive/samba/2012-May/167381.html. > > Is CYGWIN mistaking the Samba share for a FAT32 > volume and using an inode-faking algo? Or It depends on what Samba returns as file system information. Right now Cygwin expects valid inode information only from filesystems which return the FILE_PERSISTENT_ACLS flag, except for netapps (never) and nfs (always). Additionally, the returned file ID must be > 0xffffffff, otherwise we don't trust the server to generate usefule file IDs. This usually only affects remote NT4 NTFS and Samba < 3.0. Assuming your Samba drive is //server/share, please run /usr/lib/getVolInfo //server/share and post the output as reply here. As an example, this is what my Samba shares return: $ /usr/lib/csih/getVolInfo.exe //server/share Device Type : 7 Characteristics : 10 Volume Name : Serial Number : 2469776470 Max Filenamelength : 255 Filesystemname : Flags : 1002f FILE_CASE_SENSITIVE_SEARCH : TRUE FILE_CASE_PRESERVED_NAMES : TRUE FILE_UNICODE_ON_DISK : TRUE FILE_PERSISTENT_ACLS : TRUE <- !!! FILE_FILE_COMPRESSION : FALSE FILE_VOLUME_QUOTAS : TRUE FILE_SUPPORTS_SPARSE_FILES : FALSE FILE_SUPPORTS_REPARSE_POINTS: FALSE FILE_SUPPORTS_REMOTE_STORAGE: FALSE FILE_VOLUME_IS_COMPRESSED : FALSE FILE_SUPPORTS_OBJECT_IDS : TRUE FILE_SUPPORTS_ENCRYPTION : FALSE FILE_NAMED_STREAMS : FALSE FILE_READ_ONLY_VOLUME : FALSE FILE_SEQUENTIAL_WRITE_ONCE : FALSE FILE_SUPPORTS_TRANSACTIONS : FALSE If your Samba doesn't set FILE_PERSISTENT_ACLS to TRUE, you have to change your smb.conf file so that it does. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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