bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Linux 2.6 PATCH] support for Hurd ext2 format extensions


From: Michael Banck
Subject: Re: [Linux 2.6 PATCH] support for Hurd ext2 format extensions
Date: Wed, 24 Mar 2004 14:53:45 +0100
User-agent: Mutt/1.5.5.1+cvs20040105i

On Tue, Mar 23, 2004 at 10:56:17PM -0500, Roland McGrath wrote:
> > If I just tar up /dev/fd and/or /dev/zero as well as an arbitrary file
> > afterwards, I get the following:
> > 
> > star: Numerical result out of range. Cannot setxattr for 'bin/true'.
> > 
> > If I (addtionally to one of those two device files above) tar up one of
> > /dev/tty[a-z]*, I get instead:
> > 
> > star: Operation not supported. Cannot setxattr for 'bin/true'.
> > 
> > I did not have the time to run star through gdb yet. If you think that
> > would be worthwhile, I can do it of course.
> 
> Yeah, please figure out exactly what the setxattr calls that fail are,
> and check any getxattr et al calls to make sure their results look sane.

I ran star through strace for the time being, tarring up /dev/console
(in order not clutter up the differences with initialization stuff),
/dev/{fd,zero,full} (/dev/full does not make any problems)
/dev/{tty1,ttyp0} (again /dev/tty1 seems fine) and /bin/true.

This is the getfattr output on these files, which looks alright to me:

dagobert/mnt$ getfattr -d -m "gnu.*" dev/{console,fd,full,tty1,ttyp0,zero}
# file: dev/console
gnu.translator="/hurd/term\000/dev/console\000device\000console\000"

# file: dev/fd
gnu.translator="/hurd/magic\000--directory\000fd\000"

# file: dev/full
gnu.translator="/hurd/null\000--full\000"

# file: dev/tty1
gnu.translator="/hurd/term\000/dev/tty1\000hurdio\000/dev/vcs/1/console\000"

# file: dev/ttyp0
gnu.translator="/hurd/term\000/dev/ttyp0\000pty-slave\000/dev/ptyp0\000"

# file: dev/zero
gnu.translator="/hurd/storeio\000-Tzero\000"


Tracing the creation of the archive did not bring up anything
suspicious, as far as I can tell:

@@ -170,31 +170,31 @@
 fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x40968000
 write(1, "a dev/console 0 bytes, 0 tape bl"..., 37) = 37
-lstat64("dev/fd", {st_mode=S_IFREG|0666, st_size=0, ...}) = 0
-listxattr("dev/fd", (nil), 0)           = 15
-listxattr("dev/fd", 0x808c348, 15)      = 15
-getxattr("dev/fd", "gnu.translator", (nil), 0) = 27
-getxattr("dev/fd", "gnu.translator", 0x808c3a8, 27) = 27
-write(1, "a dev/fd 0 bytes, 0 tape blocks\n", 32) = 32
+lstat64("dev/full", {st_mode=S_IFREG|0666, st_size=0, ...}) = 0
+listxattr("dev/full", (nil), 0)         = 15
+listxattr("dev/full", 0x808c348, 15)    = 15
+getxattr("dev/full", "gnu.translator", (nil), 0) = 18
+getxattr("dev/full", "gnu.translator", 0x808c3a8, 18) = 18
+write(1, "a dev/full 0 bytes, 0 tape block"..., 34) = 34
 lstat64("dev/tty1", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
 listxattr("dev/tty1", (nil), 0)         = 15


It seems that after extracting /dev/fd or /dev/zero, a setxattr is
attempted for every file (diff between /dev/full and /dev/fd): 

@@ -248,20 +249,33 @@
 write(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0l\211\4"...,
        9752) = 9752
 fsync(4)                                = 0
 close(4)                                = 0
-utimes("bin/true", {1080130122, 999583}) = 0
+utimes("bin/true", {1080129902, 965034}) = 0
 chmod("bin/true", 0755)                 = 0
+setxattr("bin/true", "", 0x808c2a0, 47, ) = -1 ERANGE (Numerical result
        out of range)
+write(2, "star: Numerical result out of ra"..., 69star: Numerical
        result out of range. Cannot setxattr for 'bin/true'.
+) = 69
 lchown32("bin/true", 0, 0)              = 0

The second parameter of setxattr() is "" except when in the meantime
/dev/ttyp* got extracted, in which case it is "p*" (here, /dev/fd
/dev/ttyp0 and /bin/true got archived), yielding the EOPNOTSUP:

@@ -248,20 +249,33 @@
 write(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0l\211\4"...,
        9752) = 9752 fsync(4)                                = 0
 close(4)                                = 0
-utimes("bin/true", {1080130122, 999583}) = 0
+utimes("bin/true", {1080130145, 576151}) = 0
 chmod("bin/true", 0755)                 = 0
+setxattr("bin/true", "p0", 0x808c250, 43, ) = -1 EOPNOTSUPP (Operation
        not supported)
+write(2, "star: Operation not supported. C"..., 63star: Operation not
        supported. Cannot setxattr for 'bin/true'.
+) = 63
 lchown32("bin/true", 0, 0)              = 0

Additionally, there's a SIGCHLD quite early, before any setxattr's were
attempted:

@@ -165,9 +165,10 @@
 read(4, "TZif\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\10"...,
4096) = 837
 close(4)                                = 0
 munmap(0x40968000, 4096)                = 0
-write(1, "Dumpdate    1080130145.569563000"..., 60) = 60
+write(1, "Dumpdate    1080130178.796757000"..., 60) = 60
 write(1, "Volno       1\n", 14)         = 14
 write(1, "Blocksize   20\n", 15)        = 15
+--- SIGCHLD (Child exited) @ 0 (0) ---
 open("/etc/passwd", O_RDONLY)           = 4
 fcntl64(4, F_GETFD)                     = 0
 fcntl64(4, F_SETFD, FD_CLOEXEC)         = 0

Tracing the extraction of slightly different files yielded the SIGCHLD
at a slightly different position:

@@ -165,7 +165,8 @@
 read(4, "TZif\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\10"...,
4096) = 837
 close(4)                                = 0
 munmap(0x40968000, 4096)                = 0
-write(1, "Dumpdate    1080130145.569563000"..., 60) = 60
+--- SIGCHLD (Child exited) @ 0 (0) ---
+write(1, "Dumpdate    1080129944.159300000"..., 60) = 60
 write(1, "Volno       1\n", 14)         = 14
 write(1, "Blocksize   20\n", 15)        = 15
 open("/etc/passwd", O_RDONLY)           = 4


I've put up the full traces at http://people.debian.org/~mbanck/traces/.


Michael

-- 
Michael Banck
Debian Developer
mbanck@debian.org
http://www.advogato.org/person/mbanck/diary.html




reply via email to

[Prev in Thread] Current Thread [Next in Thread]