Hi, following up on this issue from last year. The message I'm replying to is at <https://cygwin.com/ml/cygwin/2014-04/msg00524.html>.
The problem is weird behavior in Parallels Desktop-hosted Windows VMs, when accessing the host's native Mac OS X filesystem. See the thread for the details. On Wednesday, April 23 2014, "Corinna Vinschen" wrote to "cygwin@cygwin.com" saying: > > At this point this is looking pretty clearly like a Parallels Tools bug. > > I'll report it to them. > > Yes, that sounds good. Given that, I'm wondering if we should try to > workaround this problem at all or rather wait to see if the vendor will > fix the issue. No such luck, despite two major version revisions of Parallels Desktop (I'm now on version 11.0.2) and moving to Windows 10 as the guest OS -- the bug perists, unchanged. So it looks like Cygwin will need to add a workaround for this filesystem to fix the problem. The output of /usr/lib/csih/getVolInfo seems to be unchanged from the output I reported last year. > Thanks. This looks pretty much like a filesystem pretending to be > FAT-like. There may be another problem lurking, which is, are the inode > numbers (called "FileId" or "IndexNumber" in Windows) persistant? With > FAT this is not the case, and given the above, it might be a problem... > > ...or not. I just realize that Cygwin doesn't even try to use the > FileId as inode number on filesystems with FILE_PERSISTENT_ACLS==FALSE > so, never mind. > > OTOH, does it support hardlinks? If so, two hardlinks to the > same file would have different inode numbers on Cygwin. How would I figure these points out? -- Jonathan Lennox len...@cs.columbia.edu -- 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