> > > Other programs trying to operate on these files via ext2fs also fail > > > with the same notion, (e.g. md5). And extracting these files from a > > > tarball also result in the same error. > > > > What tarball? > > I also tried placing the "corrupted" files in a tarball under Debian to > see if it could have anything to do with file-names or whatever, but > once the "corrupted" files were reached it gave me the same read error. > (this was also done on the ext3 fs)
Sigh, "files were reached". Meaning what? As soon as the tar'ing Debian system got to them, while creating the tarball, it failed with a read error? Do you mean to say you already have read problems on the (source) Debian system? Or as soon as the untar'ing OpenBSD system "reached" those files while reading the tarball, it did what? Failing to read the tarball is not the same error as failing to read the original files. You need to tell us what _exactly_ you did, and what _exactly_ happened; preferably with a script(1). > > > When moving these files over via nfs the problem doesn't occur and the > > > files are saved correctly on my ffs partition. > > > > That (or scp) is how I always copied files > > from one FS/OS/arch to a completely different FS/OS/arch. > > > And my point isn't the migration of my data. There is a work-around so I > already fixed that. That's not a workaround. You cannot take a disk holding a certain filesystem from a certain OS on a certain architecture, put it into a different machine of a different architecture, running a different OS, mount it as a different filesystem, and just expect it to work. Going through a defined protocol such as NFS of SCP is the normal way.
