Hello, I believe I've tripped across a pax regression. When running pax in -rw mode, the files it creates in the destination tree all have their last byte replaced by a null.
I only see this behavior in a sol10.sun4 build. The same source tree built on linux.i386 seems to behave. The build is from ast-open.2012-08-01.tgz. I haven't messed with any build options or anything like that, it's quite default. The build finds and uses Sun C 5.9 installed in /opt/SUNWspro. It's pretty easy to reproduce. The example here shows one file, but if I create multiple files in a/ they all exhibit the problem under b/. $ rm -fr a b $ mkdir a $ print hello >a/hello $ mkdir b $ ast pax -rw a b 1 block $ od -c a/hello 0000000 h e l l o \n 0000006 $ od -c b/a/hello 0000000 h e l l o \0 0000006 Interestingly, according to truss, each file is written correctly, at first. But then there's an seek on the output file to the last byte, which is then overwritten with a single byte write of a null. ... open64("b/a/hello", O_WRONLY|O_CREAT|O_TRUNC, 0664) = 3 open64("a/hello", O_RDONLY) = 4 llseek(4, 0, SEEK_HOLE) = 6 llseek(4, 0, SEEK_SET) = 0 read(4, " h e l l o\n", 6) = 6 llseek(3, 0, SEEK_SET) = 0 write(3, " h e l l o\n", 6) = 6 llseek(4, 6, SEEK_DATA) Err#6 ENXIO llseek(4, 0xFFFFFFFFFFFFFFFF, SEEK_END) = 5 llseek(3, 5, SEEK_SET) = 5 write(3, "\0", 1) = 1 close(3) = 0 close(4) = 0 ... I'm quite willing to look at other distributions of ast-open if it'll help isolate the cause of, or develop a fix for, this bug. Let me know how I can help, Bob -- Bob Krzaczek, Chester F. Carlson Center for Imaging Science, RIT phone +1-585-4757196, email k...@cis.rit.edu, icbm 43.08586N 77.67744W
pgpQMEZ9YKKdh.pgp
Description: PGP signature
_______________________________________________ ast-developers mailing list ast-developers@research.att.com https://mailman.research.att.com/mailman/listinfo/ast-developers