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 [email protected], icbm 43.08586N 77.67744W
pgpQMEZ9YKKdh.pgp
Description: PGP signature
_______________________________________________ ast-developers mailing list [email protected] https://mailman.research.att.com/mailman/listinfo/ast-developers
