[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200810261425.58892.agruen@suse.de>
Date: Sun, 26 Oct 2008 14:25:58 +0100
From: Andreas Gruenbacher <agruen@...e.de>
To: Hugh Dickins <hugh@...itas.com>,
Rob MacKinnon <c4blem0nkey@...il.com>
Cc: Stephen Smalley <sds@...ho.nsa.gov>, linux-kernel@...r.kernel.org
Subject: Re: tmpfs support of xattrs?
On Sunday, 26 October 2008 13:26:35 Hugh Dickins wrote:
> On Sat, 25 Oct 2008, Rob MacKinnon wrote:
> > The background: So during the initial configuration of a box I enabled
> > the xattr flags for ext3 and options of xattr in coreutils, and at the
> > time didn't realize that I'd hit a snag that would finally annoy me
> > enough after a month of getting a non-fatal error messages from cp "cp:
> > listing attributes of `/dev/null`: Invalid argument" to spend half a day
> > researching the cause and a potential solution.
> >
> > Setup: udev mounts a tmpfs to /dev then fills it with device nodes.
> > Problem: the resulting tmpfs has no xattr support.
> > Therefore: Tmpfs without xattrs, and coreutils and everywhere else with
> > xattr support, cp freaks.
> >
> > Is there sometime in the forseable future when the tmpfs module will
> > support for xattrs in the stable branch, or should I "holler at the
> > maintainers of coreutils to fix their broken code in cp". Even better
> > (and I like this option the most) a little of both?
>
> I've not seen "cp: listing attributes of `/dev/null': Invalid argument"
> messages (or.. do I have a dim recollection of them once upon a time?).
> I would certainly get irritated by them if I did, and want to fix them.
> I tried "cp /dev/null temp" on a few distros just now but not seen it.
As Hugh pointed out already, tmpfs does support xattrs since quite a while, so
enabling that should fix the symptoms. Independent of that, cp must of course
work correctly on filesystems that don't have xattrs. Those filesystems are
not supposed to return EINVAL, though.
Could you please run cp under strace to show us what's happening at the
syscall level (and perhaps under ltrace in addition to see the library level
as well)?
If the error happens at the syscall level (*listxattr), then which kernel is
it exactly, and where can I find its sources?
Thanks,
Andreas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists