[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [linux 2.6 patch] ext2 support for hurd extensions via xattr interfa
From: |
Michael Banck |
Subject: |
Re: [linux 2.6 patch] ext2 support for hurd extensions via xattr interface |
Date: |
Thu, 26 Feb 2004 17:08:02 +0100 |
User-agent: |
Mutt/1.5.5.1+cvs20040105i |
On Thu, Feb 12, 2004 at 11:19:42PM -0800, Roland McGrath wrote:
> Hi folks. I've just whipped up the following patch, which is against the
> current Linux 2.6 source tree. This provides a means to fetch and store
> the extra data stored in nodes on ext2 filesystems with "creator_os" set to
> EXT2_OS_HURD, i.e. from `mke2fs -o hurd' or filesystems created natively on
> the Hurd.
Just curious, would it not make sense to have this for ext3, too? After
all, one can mount ext3 filesystems as ext2 on GNU/Hurd (AFAIK), so
extracting passive translators on a (incidently) ext3 file system for
later use on GNU/Hurd might make sense (although I admit this might not
be a common operation). Linux-2.6 has separate config options for
extended attributes for ext2 and ext3, so I assume the latter is not
supported right now. Is there a fundamental problem with ext3, or did
you just not do it for ext2?
> It also makes it possible to back up and restore a Hurdish ext2
> filesystem from a GNU/Linux system, using any tools that understand
> the extended attributes. (Off hand the only such thing I'm aware of
> is `star', which I have not tried using myself.)
I tried using star, but I get errors when I try to extract /gnu/servers.
I am not sure whether this is expected to work at all, though, as I get
EOPNOTSUPP.
I used 'star artype=exustar -xattr -c -v -f servers.tar /gnu/servers' as
command-line for tarring up the translators and 'star artype=exustar
-xattr -x -v -f servers.tar' for extracting. Tarring up seems to work
fine, but subsequent extracting yields error messages like this:
star: Operation not supported. Cannot setxattr for 'gnu/servers/exec'.
strace:
[...]
lstat64("gnu/servers/exec", 0xbfffd440) = -1 ENOENT (No such file or directory)
write(1, "x gnu/servers/exec 0 bytes, 0 ta"..., 42) = 42
open("gnu/servers/exec", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 4
fcntl64(4, F_GETFL) = 0x8001 (flags O_WRONLY|O_LARGEFILE)
fstat64(4, {st_mode=S_IFREG|0664, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40975000
_llseek(4, 0, [0], SEEK_CUR) = 0
munmap(0x40975000, 4096) = 0
fcntl64(4, F_GETFD) = 0
fcntl64(4, F_GETFD) = 0
fsync(4) = 0
close(4) = 0
utimes("gnu/servers/exec", {1057965161, 0}) = 0
chmod("gnu/servers/exec", 0644) = 0
setxattr("gnu/servers/exec", "gnu.translator", 0x808c110, 11, ) = -1 EOPNOTSUPP
(Operation not supported)
write(2, "star: Operation not supported. C"..., 71star: Operation not
supported. Cannot setxattr for 'gnu/servers/exec'.
) = 71
utimes("gnu/servers/exec", {1057965161, 0}) = 0
[...]
I then tried to debug star (you have to add '-g' to a read-only file in
RULES/foo-linux-cc, d'oh) and libattr, and it seems either the functions
arguments get corrupted when calling setxattr() or my mundane gdb skills
are at their limit here.
This is when tarring up the translator:
Breakpoint 7, get_xattr (info=0xbfffd4a0) at xattr.c:57
57 {
66 free_xattr(&static_xattr);
$65 = {f_tcb = 0x40171a00, f_name = 0xbfffd4a0 "/gnu/servers/exec",
f_namelen = 19, f_lname = 0xbfffa420 "", f_lnamelen = 0, f_uname = 0x0,
f_umaxlen = 0, f_gname = 0x0, f_gmaxlen = 0, f_dir = 0x808c100 "",
f_dirinos = 0x0, f_dirlen = 20, f_dirents = 4, f_dev = 782, f_ino = 57353,
f_nlink = 1, f_mode = 420, f_uid = 0, f_gid = 0, f_size = 0, f_rsize = 0,
f_contoffset = 137573730948, f_flags = 0, f_xflags = 7, f_xftype = 1,
f_rxftype = 1, f_filetype = 1, f_typeflag = 0 '\0', f_type = 32768,
f_rdev = 0, f_rdevmaj = 0, f_rdevmin = 0, f_atime = 1057965161, f_ansec = 0,
f_mtime = 1057965161, f_mnsec = 0, f_ctime = 1057965535, f_cnsec = 0,
f_fflags = 0, f_acl_access = 0xbffff7f0 "",
f_acl_default = 0x40171000 "././@PaxHeader", f_xattr = 0x808c0f0}
[...]
$74 = {name = 0x808c0f0 "gnu.translator", value = 0x808c040, value_len = 11}
[...]
$79 = 0x808c040 "/hurd/exec"
And this is when extracting it:
Breakpoint 3, set_xattr (info=0x1) at xattr.c:164
164 {
168 if (info->f_xattr == NULL)
$134 = {f_tcb = 0xbffff560, f_name = 0xbfffe551 "gnu/servers/exec",
f_namelen = 0, f_lname = 0xbfffd540 "", f_lnamelen = 0,
f_uname = 0xbffff669 "root", f_umaxlen = 32, f_gname = 0xbffff689 "nobody",
f_gmaxlen = 32, f_dir = 0x0, f_dirinos = 0x0, f_dirlen = 0, f_dirents = 0,
f_dev = 0, f_ino = 0, f_nlink = 0, f_mode = 420, f_uid = 0, f_gid = 0,
f_size = 0, f_rsize = 0, f_contoffset = 0, f_flags = 0, f_xflags = 524295,
f_xftype = 1, f_rxftype = 1, f_filetype = 1, f_typeflag = 48 '0',
f_type = 32768, f_rdev = 0, f_rdevmaj = 0, f_rdevmin = 0,
f_atime = 1057965161, f_ansec = 0, f_mtime = 1057965161, f_mnsec = 0,
f_ctime = 1057965535, f_cnsec = 0, f_fflags = 0, f_acl_access = 0x0,
f_acl_default = 0x0, f_xattr = 0x808c0b0}
$135 = {name = 0x808c0d0 "gnu.translator", value = 0x808c100, value_len = 11}
$136 = 0x808c100 "/hurd/exec"
171 for (xap = info->f_xattr; xap->name != NULL; xap++) {
172 if (setxattr(info->f_name, xap->name, xap->value,
173 xap->value_len, 0) != 0) {
setxattr (path=0xbfffe551 "gnu/servers/exec",
name=0xbfffe551 "gnu/servers/exec", value=0xbfffe551, size=3221218641,
flags=-1073748655) at syscalls.c:213
213 return SYSCALL(__NR_setxattr, path, name, value, size, flags);
$137 = 0xbfffe551 "gnu/servers/exec"
$138 = 0xbfffe551 "gnu/servers/exec"
$139 = 0xbfffe551 "gnu/servers/exec"
214 }
set_xattr (info=0xbffff820) at xattr.c:174
174 if (!errhidden(E_SETXATTR, info->f_name)) {
175 errmsg("Cannot setxattr for '%s'.\n",
176 info->f_name);
177 xstats.s_setxattr++;
Anyway, one problem is that star (or whoever else) seems to cut off after
the first "\0":
$144 = (star_xattr_t *) 0x808c0b0
$145 = {name = 0x808c0d0 "gnu.translator", value = 0x808c100, value_len = 72}
$146 = 0x808c100 "/hurd/pfinet"
> bash$ getfattr -Rh -d -m '.*' /gnu/servers getfattr: Removing
> leading '/' from absolute path names # file:
> gnu/servers/socket/1 gnu.translator="/hurd/pflocal\000"
[...]
This worked well for me.
Sorry if I might have totally missed the point,
Michael
Re: [linux 2.6 patch] ext2 support for hurd extensions via xattr interface, Ognyan Kulev, 2004/02/13
Re: [linux 2.6 patch] ext2 support for hurd extensions via xattr interface, Michael Banck, 2004/02/15
Re: [linux 2.6 patch] ext2 support for hurd extensions via xattr interface,
Michael Banck <=
Re: [linux 2.6 patch] ext2 support for hurd extensions via xattr interface, Michael Banck, 2004/02/27
Re: [linux 2.6 patch] ext2 support for hurd extensions via xattr interface, Roland McGrath, 2004/02/27
Re: [linux 2.6 patch] ext2 support for hurd extensions via xattr interface, Michael Banck, 2004/02/27