In message <20051112185731.GA2750@home.chello.upc.cz>, Jaromir Dolecek writes:
>On Sat, Nov 12, 2005 at 01:52:26PM -0500, Steven M. Bellovin wrote:
>> Presumably, though, the behavior of linux_sys_read would have to depend 
>> on the underlying file system type -- it does the right thing for, say, 
>> ffs and ext2fs, but not for tmpfs.
>
>Can we summarize what's the problem on tmpfs?
>
>
The symptom is that some applications -- I'm seeing it with openoffice2 
-- can't read tmpfs directories via linux emulation.  A posting by Thor 
summarizes it:

Subject: Re: problem with tmpfs and linux emulation?
From: Thor Lancelot Simon <tls@rek.tjls.com>
Date: Wed, 9 Nov 2005 10:48:41 -0500
To: "Steven M. Bellovin" <smb@cs.columbia.edu>
Cc: current-users@netbsd.org

On Wed, Nov 09, 2005 at 10:40:21AM -0500, Steven M. Bellovin wrote:
> 
> What, precisely, is the problem?  What is there about tmpfs that a 
> application can detect?

Linux's libc relies on knowledge of the internal structure of directory
entries rather than manipulating them with the appropriate system calls.
This causes chaos for those porting filesystems to Linux (e.g. XFS, JFS),
as well as for those emulating Linux on other systems (e.g. us) or serving
directories to Linux over network filesystems (because the Linux clients
don't translate the structure of directories on read(2) either).

We don't encounter this problem with most local filesystems because the
in-core directory data structures used by UFS are "close enough".  But
we have a nasty hack to work around it for NFS (which has a performance
impact, as well as a significant code complexity impact) and we have
trouble with filesystems that can't trivially provide directory structures
that look like Linux libc wants them to.

I have always wondered what Linux does with foreign filesystems like FAT
and NTFS.  I assume that if you try to read a directory, their kernel just
lies.


		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb