This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: [1.7] Samba file cp
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/