From: Stephen Tweedie <sct@redhat.com>
To: Nathan Scott <nathans@sgi.com>
Cc: Andi Kleen <ak@suse.de>, Linus Torvalds <torvalds@transmeta.com>,
Andreas Gruenbacher <ag@bestbits.at>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
acl-devel@bestbits.at, linux-xfs@oss.sgi.com
Subject: Re: [Acl-Devel] Re: [RFC][PATCH] extended attributes
Date: Thu, 8 Nov 2001 01:26:10 +0000 [thread overview]
Message-ID: <20011108012610.C12638@redhat.com> (raw)
In-Reply-To: <20011107111224.C591676@wobbly.melbourne.sgi.com> <20011107023218.A4754@wotan.suse.de> <20011107141956.F591676@wobbly.melbourne.sgi.com>
In-Reply-To: <20011107141956.F591676@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Wed, Nov 07, 2001 at 02:19:56PM +1100
Hi,
On Wed, Nov 07, 2001 at 02:19:56PM +1100, Nathan Scott wrote:
> On Wed, Nov 07, 2001 at 02:32:18AM +0100, Andi Kleen wrote:
> > EA_FIRST_ENTRY to reset the fd the first entry, EA_READ_ENTRY to
> > read the next one.
>
> I'm not sure this would work for the extattr/lextattr variants where
> we don't have an fd to hold the state.
> eg. the opening of the file before allowing a list operation could
> have implications for XFSs DMAPI support (open might recall data from
> tape),
There are other much more immediate obstacles: opening /dev/* is not
possible if the devices beneath the inodes don't exist.
O_OPENONLY (implying neither read nor write access) to get a stub file
handle for such inodes is possible, if a bit hackish. There's a
problem in the kernel there --- kernel file descriptor operations on
"special" inodes such as named sockets/pipes or device nodes don't
pass file operations on to the underlying filesystem.
As long as you're doing the ACL stuff via inode operations internally,
that's not a problem. However, inode operations generally don't take
a file descriptor as an argument so you don't have access to the
cursor in that case.
The DMAPI and special inode problems go away if you don't demand a
file descriptor to the file. (Having a file descriptor that
specifically belongs to the ACL stream is a different matter
entirely.)
--Stephen
next prev parent reply other threads:[~2001-11-08 1:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-07 0:12 [RFC][PATCH] extended attributes Nathan Scott
2001-11-07 0:23 ` Nathan Scott
2001-11-07 1:32 ` Andi Kleen
2001-11-07 1:38 ` Alexander Viro
2001-11-07 3:19 ` Nathan Scott
2001-11-08 1:26 ` Stephen Tweedie [this message]
2001-11-08 6:48 ` Andi Kleen
2001-11-12 5:01 ` Nathan Scott
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20011108012610.C12638@redhat.com \
--to=sct@redhat.com \
--cc=acl-devel@bestbits.at \
--cc=ag@bestbits.at \
--cc=ak@suse.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@oss.sgi.com \
--cc=nathans@sgi.com \
--cc=torvalds@transmeta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.