Jan Stary schreef op zo 30-12-2012 om 13:49 [+0100]: > > > > 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).
What I did was as follow: martijn@debian:~$ tar -cf /path/to/e2fs/archive.tar \ /path/to/e2fs/sanefile /path/to/e2fs/corruptfile martijn@debian:~$ md5sum /path/to/e2fs/sanefile d93b7c75f55c4de770c3c038a2fef3a6 /path/to/e2fs/sanefile martijn@debian:~$ md5sum /path/to/e2fs/corruptfile 8a8535e6c0cbd85c0cfedb30606b9d71 /path/to/e2fs/corruptfile <attach disk to OBSD> martijn@OBSD$ tar -xf /path/to/e2fs/archive.tar tar: Failed read on archive volume 1: Invalid argument tar: Attempting to recover from an archive read failure. martijn@OBSD$ md5 /path/to/e2fs/corruptfile md5: /path/to/e2fs/corruptfile: read error: Invalid argument martijn@OBSD$ md5 /path/to/e2fs/sanefile MD5: (/path/to/e2fs/sanefile) = d93b7c75f55c4de770c3c038a2fef3a6 Of course the archive and corruptfile works correct on my Linux systems. > > > > > 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. > This should not be an issue (this is also my response to Rogier). Ext3 is nothing more than ext2 with extra journaling features enabled, so the disk should be able to be usable (for the majority of the files it is). It should also be architecture independent since everything is stored in little endian bite-order.[1] If a filesystem isn't a "defined protocol" then it shouldn't be offered as a mountable filesystem. And your response still hasn't given me an answer to my question. How can I trace where/how these read-errors occur? [1] http://disktype.sourceforge.net/doc/ch03s05.html#id894875
