Matt Seitz (matseitz) wrote:
From: Larry Hall (Cygwin)
Matt Seitz (matseitz) wrote:
Matt Seitz (matseitz) wrote:
This problem and a proposed solution was mentioned in an earlier
e'mail
(http://www.cygwin.com/ml/cygwin/1998-09/msg00839.html).
Ah, yes, the mounted CIFS share is reported as a FAT file
system*.
That's it I expect. Going straight to the code, in
fhandler_disk_file.cc, here's some code from
fhandler_base::fstat_helper():
/* 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_namehash ();
One of the things that isgood_inode() checks for is that it's
not a FAT drive. In case it is, you end up with a faked hash inode.
Thanks for the diagnosis. I'm curious about something. The message I
reference above also mentioned an issue with "st_dev". It seems to imply
that correcting the "st_dev" to use the volume serial number could resolve
this issue. What is your opinion on that theory?
Given that the message you found refers to code that's a good 10 years
old, I think it's safe to assume that things here have changed. ;-)
And they have. I found no "42" anywhere in the code that is related
to st_dev. So that "oddness" is now gone.
--
Larry Hall http://www.rfk.com
RFK Partners, Inc. (508) 893-9779 - RFK Office
216 Dalton Rd. (508) 893-9889 - FAX
Holliston, MA 01746
_____________________________________________________________________
A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?
--
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/
