Hi folks, I'm trying the restore a dump, which I have encrypted with the bdes(1) utility, from a mounted 5.3-RELEASE fixit CD (cd2 i386). I have encrypted the dump with the same bdes that is on that CD. I use a pipeline that looks something like /mnt2/usr/bin/bdes -d <dumpfile |/mnt2/sbin/restore -tf - (to view the dump) and after a couple kilobytes that seem to get through, I always get a stream of : fwrite error at 8 messages from bdes and decryption fails. Decryption works without problems on another machine on an ordinary 5.3-STABLE installation. From looking at bdes.c, the message gets written on short writes (fwrite wrote less than requested). Instead of trying to write the rest, the author decided to just print a warning and that was it. Amazingly, the message doesn't get printed in a "bdes|cat" pipeline. Only when restore is being used does it seem to happen. Is there anything odd with shell pipelines on the fixit disk? It doesn't matter if I use sh or tcsh for running the pipeline. On a side note, there seem to be other problems with the 5.3 fixit disk.. one has to symlink /mnt2/usr/bin to /usr/bin because otherwise scp won't find the ssh executable, and "mount" complains about "nfs not compiled in" but there's a mount_nfs utility which works ok. Editing a disklabel with "bsdlabel -e device" won't work, since bsdlabel complains about "/mnt2/stand/vi: No such file or directory" and one has to set EDITOR to "vi", or an existing pathname, in order to get it to work. All in all, makes a bit of an unpolished appearance.. hasn't the stuff been tested in a while? mkb.
Matthias Buelow <mkb@incubus.de> writes:> Instead of trying to write the rest, the author decided to just print > a warning and that was it.That's bad. Short writes are perfectly valid, bdes should learn to handle them properly.> Amazingly, the message doesn't get printed in a "bdes|cat" pipeline. > Only when restore is being used does it seem to happen.Probably because cat uses a large enough buffer and reads fast enough to completely empty the pipe for every read, so bdes never gets a short write (caused by a partially full buffer). DES -- Dag-Erling Sm?rgrav - des@des.no
Matthias Buelow <mkb@incubus.de> wrote:> Hi folks, > > I'm trying the restore a dump, which I have encrypted with the bdes(1) > utility, from a mounted 5.3-RELEASE fixit CD (cd2 i386). > > I have encrypted the dump with the same bdes that is on that CD. > I use a pipeline that looks something like > > /mnt2/usr/bin/bdes -d <dumpfile |/mnt2/sbin/restore -tf - > > (to view the dump) and after a couple kilobytes that seem to get > through, I always get a stream of > > : fwrite error at 8 > > messages from bdes and decryption fails. > Decryption works without problems on another machine on an ordinary > 5.3-STABLE installation. From looking at bdes.c, the message gets > written on short writes (fwrite wrote less than requested). > Instead of trying to write the rest, the author decided to just print > a warning and that was it. > > Amazingly, the message doesn't get printed in a "bdes|cat" pipeline. > Only when restore is being used does it seem to happen. > Is there anything odd with shell pipelines on the fixit disk? > It doesn't matter if I use sh or tcsh for running the pipeline. > > On a side note, there seem to be other problems with the 5.3 fixit > disk.. one has to symlink /mnt2/usr/bin to /usr/bin because otherwise > scp won't find the ssh executable, and "mount" complains about "nfs not > compiled in" but there's a mount_nfs utility which works ok. Editing a > disklabel with "bsdlabel -e device" won't work, since bsdlabel complains > about "/mnt2/stand/vi: No such file or directory" and one has to set > EDITOR to "vi", or an existing pathname, in order to get it to work. > All in all, makes a bit of an unpolished appearance.. hasn't the stuff > been tested in a while? > > mkb.