I had some problems to read a OpenBSD ufs filesystem (with kernel 2.0.30 +
ufs.diff.gz from vger).
First problem: ufs screws up fast symlinks when reading a byteswapped
filesystem (i.e. sparc fs on a intel box). Fix below.
Second problem: OpenBSD uses a (new?) directory entry format which is
different from what linux expects to find. From sys/ufs/ufs/dir.h:
---------------------
struct direct {
u_int32_t d_ino; /* inode number of entry */
u_int16_t d_reclen; /* length of this record */
u_int8_t d_type; /* file type, see below */
u_int8_t d_namlen; /* length of string in d_name */
char d_name[MAXNAMLEN + 1];/* name with length <= From owner-linux-kernel-outgoing@vger.rutgers.edu Thu Aug 21 15:40:47 1997
Received: from i-m-f.org ([208.205.20.18])
by herbie.ucs.indiana.edu (8.8.7/8.8.7) with SMTP id PAA06060
for <linuxkernel@uwsg.indiana.edu>; Thu, 21 Aug 1997 15:40:46 -0500 (EST)
Received: from vger.rutgers.edu [128.6.190.2] (root)
by i-m-f.org with esmtp (Exim 1.625 #1)
id 0x1dyL-0005sf-00 (Debian); Thu, 21 Aug 1997 13:36:49 -0700
Received: by vger.rutgers.edu id <971682-14772>; Thu, 21 Aug 1997 16:25:24 -0400
Received: from ns.weiden.de ([193.203.186.3] EHLO ns.weiden.de ident: IDENT-NOT-QUERIED [port 3921]) by vger.rutgers.edu with ESMTP id <971702-14772>; Thu, 21 Aug 1997 16:24:02 -0400
Received: from mikeg.weiden.de (mikeg@mikeg.weiden.de [193.203.186.200])
by ns.weiden.de (8.8.5/8.8.5) with ESMTP id WAA05095;
Thu, 21 Aug 1997 22:20:25 +0200 (MET DST)
Received: from mikeg.weiden.de (mikeg@mikeg.weiden.de [193.203.186.200]) by mikeg.weiden.de (8.8.3/8.8.3) with SMTP id WAA00322; Thu, 21 Aug 1997 22:18:55 +0200
Date: Thu, 21 Aug 1997 22:18:55 +0200 (MET DST)
From: "Michael L. Galbraith" <mikeg@weiden.de>
To: Pete Harlan <harlan@mymenus.com>
cc: Rogier Wolff <R.E.Wolff@BitWizard.nl>, johnsonm@redhat.com,
linux-kernel@vger.rutgers.edu, tiensivu@pilot.msu.edu
Subject: Re: pre-2.0.31-7 nit picks
In-Reply-To: <199708211919.OAA13322@mango.mymenus.com>
Message-ID: <Pine.LNX.3.95.970821220959.293A-100000@mikeg.weiden.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
On Thu, 21 Aug 1997, Pete Harlan wrote:
> > Michael, what you didn't check was wether "echo" wrote that first string
> > in one "write" system call, or not. If it does something like
>
> It's (possibly) worse than just requring quotes; echo does one write
> like this:
>
> $ strace echo "123 456 789"
> execve("/bin/echo", ["echo", "123 456 789"], [/* 28 vars */]) = 0
> ...
> write(1, "123 456 789\n", 12123 456 789
>
> but it does it in two writes if you run it like this:
>
> $ strace bash -c 'echo "123 456 789"'
> execve("/bin/bash", ["bash", "-c", "echo \"123 456 789\""], [/* 28 vars */])
> write(1, "123 456 789", 11123 456 789) = 11
> write(1, "\n", 1
>
> This is with bash-2.00. Perhaps the 'file format' for the /proc
> entries should be required to end in newlines, and the filesystem
> should read everything up until the terminating newline? I don't like
> the idea of requiring a newline, but it could be less surprising than
> the current behavior.
>
> --
> Pete Harlan
> pete@mymenus.com
>
Bash-2.01.0 does..
$ strace bash -c 'echo "123 456 789"' 2>xx
execve("/bin/bash", ["bash", "-c", "echo \"123 456 789\""], [/* 43 vars */]) = 0
...
write(1, "123 456 789\n", 12123 456 789 ) = 12
I had problems with 2.00.. 2.01.0 works great.
-Mike