Mail Archives: cygwin/2009/03/12/17:05:37
On Mar 12 13:01, Brian Ford wrote:
> On Tue, 10 Mar 2009, Corinna Vinschen wrote:
> > 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?
It seems I introduced this problem with the new advisory file locking
code in 1.7. I just applied a patch which is supposed to fix your
problem. Please give it a try.
Thanks for testing,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
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/
- Raw text -