X-Recipient: archive-cygwin@delorie.com X-SWARE-Spam-Status: No, hits=-0.9 required=5.0 tests=AWL,BAYES_40 X-Spam-Check-By: sourceware.org Date: Thu, 12 Mar 2009 13:01:39 -0500 From: Brian Ford Reply-To: cygwin@cygwin.com To: cygwin@cygwin.com Subject: Re: [1.7] Samba file cp In-Reply-To: <20090310214918.GG9322@calimero.vinschen.de> Message-ID: References: <49B69EBB.4020405@gmail.com> <20090310214918.GG9322@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-IsSubscribed: yes Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com On Tue, 10 Mar 2009, Corinna Vinschen wrote: > And given the high values they seem to be faked inode numbers. But that > doesn't match the below GetVolInfo output. This flag combination should > result in identical operation on 1.7 and 1.5.25. Obviously, it doesn't ;-). > I just tested this against a samba 3.2.6 server and I can't reproduce your > problem. I'm wondering if that's something about the age of the Samba > server in your case. Old 2.x Sambas did exactly what you're seeing > above. The inode numbers are arbitrary values between each call fetching > file information from the server. See the comment in fhandler_disk_file.cc, > in function path_conv::isgood_inode(). return hasgood_inode () && (ino > UINT32_MAX || !isremote () || fs_is_nfs ()); 1 && (0 || !1 || 0) = false > As I said, it works fine for me. It would be helpful if you could debug > this situation. The important places are > > fhandler_base::fstat_helper() in fhandler_disk_file.cc for > ls(1)/stat(1)/stat(2) fhandler_disk_file.cc (fstat_helper): 531 /* Enforce namehash as inode number on untrusted file systems. */ if (pc.isgood_inode (nFileIndex)) buf->st_ino = (__ino64_t) nFileIndex; else buf->st_ino = get_ino (); So pc.isgood_inode returns false because ino is < UINT_32MAX and the other exceptions are false, but we call get_ino wich does: __ino64_t get_ino () { return ino ?: ino = hash_path_name (0, pc.get_nt_native_path ()); } and returns the non-zero ino instead of calling hash_path name? I thought we just said ino < UINT_32MAX was bad? -- Brian Ford Staff Realtime Software Engineer VITAL - Visual Simulation Systems FlightSafety International the best safety device in any aircraft is a well-trained crew... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/