Change to fs/isofs/dir.c

Richard A Frewin - QMW (star@qmw.ac.uk)
Thu, 28 Oct 1999 16:00:52 +0100 (BST)


This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.

---559023410-851401618-941043792=:1561
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.SOL.4.04.9910281428581.16629@starsun7.ph.qmw.ac.uk>

Hi,

I'll lay my cards on the table right away - a) I'm not a kernel hacker (so
I really don't understand what I'm doing), b) this patch has not been tested
widely and c) it's not really all that important anyway, however ....

I have a set of Voyager data CDs from NASA which, I think, were burned on a
VAX (they claim to conform to the ISO 9660 standard; some of the files are
"record structured" which Linux sees OK [Solaris still breaks over these]).
Under the 2.0 kernels all was fine but after upgrading to Red Hat 6.0 some of
the directory entries on the CDs vanished. All the files can still be
accessed (if you know the names) it's just that long directory listings are
truncated and errors of the form

kernel: next_offset (20c) > bufsize (200)

appear in syslog.

Hunting about in fs/isofs/dir.c I think I've found the relevant bit of code
that changed between 2.0 and 2.2 (in fact in 2.1.32) - the 2.0 code has a
comment

/* Make sure that the entire directory record is in the
current bh block.
If not, put the two halves together in "tmpde" */

which has changed to

* This would only normally happen if we had
* a buggy cdrom image. All directory
* entries should terminate with a null size
* or end exactly at the end of the sector.

Knowing NASA, I would not be surprised if they were producing "buggy cdrom
image"s but .....

Anyway, I've generated a small patch to fs/isofs/dir.c that reverses this
which applies cleanly to 2.2.5 and 2.2.12 (it should also apply to 2.3.X as it
looks like fs/isofs/dir.c has remained mostly unchanged).

I have no idea if this is the correct way to do this directory record
"reassembly" in 2.2 it just "Works For Me"[tm] (as I said, I'm not a kernel
hacker and the patch has not been extensively tested).

I'd be pleased to hear your comments. (I'm no longer subscribed to
linux-kernel as may mailbox can't take the strain and I don't have time to
read it all anymore - so could you please send comments to star@qmw.ac.uk).

Many thanks for your time,

Richard.

_______________________________________________________________
Richard A. Frewin Email: star@qmw.ac.uk
QMW Starlink Site Manager Tel: 0171 975 5053
Physics Department Fax: 0181 981 9465
Queen Mary and Westfield College http://www-star.qmw.ac.uk/
Mile End Road London E1 4NS [JoaT(MoN)]

---559023410-851401618-941043792=:1561
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="isofs-dir-0.1.patch"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.SOL.4.04.9910271803120.1561@starsun7.ph.qmw.ac.uk>
Content-Description: isofs-dir-0.1.patch
Content-Disposition: ATTACHMENT; FILENAME="isofs-dir-0.1.patch"

LS0tIGZzL2lzb2ZzL2Rpci5jLTIuMi41CVdlZCBPY3QgIDYgMTY6MTY6MTcg
MTk5OQ0KKysrIGZzL2lzb2ZzL2Rpci5jCVdlZCBPY3QgIDYgMTU6MzM6MTgg
MTk5OQ0KQEAgLTE1MSw3ICsxNTEsNyBAQA0KIAkJcmV0dXJuIDA7DQogDQog
CXdoaWxlIChmaWxwLT5mX3BvcyA8IGlub2RlLT5pX3NpemUpIHsNCi0JCWlu
dCBkZV9sZW47DQorCQlpbnQgZGVfbGVuLCBuZXh0X29mZnNldDsNCiAjaWZk
ZWYgREVCVUcNCiAJCXByaW50aygiQmxvY2ssIG9mZnNldCwgZl9wb3M6ICV4
ICV4ICV4XG4iLA0KIAkJICAgICAgIGJsb2NrLCBvZmZzZXQsIGZpbHAtPmZf
cG9zKTsNCkBAIC0xOTMsMTggKzE5Myw0MCBAQA0KIAkJCWNvbnRpbnVlOw0K
IAkJfQ0KIA0KLQkJb2Zmc2V0ICs9ICBkZV9sZW47DQotCQlpZiAob2Zmc2V0
ID4gYnVmc2l6ZSkgew0KLQkJCS8qDQotCQkJICogVGhpcyB3b3VsZCBvbmx5
IG5vcm1hbGx5IGhhcHBlbiBpZiB3ZSBoYWQNCi0JCQkgKiBhIGJ1Z2d5IGNk
cm9tIGltYWdlLiAgQWxsIGRpcmVjdG9yeQ0KLQkJCSAqIGVudHJpZXMgc2hv
dWxkIHRlcm1pbmF0ZSB3aXRoIGEgbnVsbCBzaXplDQotCQkJICogb3IgZW5k
IGV4YWN0bHkgYXQgdGhlIGVuZCBvZiB0aGUgc2VjdG9yLg0KLQkJCSAqLw0K
LQkJICAgICAgICBwcmludGsoIm5leHRfb2Zmc2V0ICgleCkgPiBidWZzaXpl
ICglbHgpXG4iLA0KLQkJCSAgICAgICBvZmZzZXQsYnVmc2l6ZSk7DQotCQkJ
YnJlYWs7DQorCQkvKiBNYWtlIHN1cmUgdGhhdCB0aGUgZW50aXJlIGRpcmVj
dG9yeSByZWNvcmQgaXMgaW4gdGhlDQorCQkgICBjdXJyZW50IGJoIGJsb2Nr
Lg0KKwkJICAgSWYgbm90LCBwdXQgdGhlIHR3byBoYWx2ZXMgdG9nZXRoZXIg
aW4gInRtcGRlIiAqLw0KKwkJbmV4dF9vZmZzZXQgPSBvZmZzZXQgKyBkZV9s
ZW47DQorCQlpZiAobmV4dF9vZmZzZXQgPiBidWZzaXplKSB7DQorI2lmZGVm
IERFQlVHDQorCQkgICAgICAgIHByaW50aygibmV4dF9vZmZzZXQgKCV4KSA+
IGJ1ZnNpemUgKCV4KVxuIixuZXh0X29mZnNldCxidWZzaXplKTsNCisjZW5k
aWYNCisJCQluZXh0X29mZnNldCAmPSAoYnVmc2l6ZSAtIDEpOw0KKwkJICAg
ICAgICBtZW1jcHkodG1wZGUsIGRlLCBidWZzaXplIC0gb2Zmc2V0KTsNCisJ
CQlicmVsc2UoYmgpOw0KKwkJCWJsb2NrID0gaXNvZnNfYm1hcChpbm9kZSwg
KGZpbHAtPmZfcG9zICsgZGVfbGVuKSA+PiBidWZiaXRzKTsNCisJCQlpZiAo
IWJsb2NrKQ0KKwkJICAgICAgICB7DQorCQkJCXJldHVybiAwOw0KKwkJCX0N
CisJCSAgDQorCQkJYmggPSBicmVhZGEoaW5vZGUtPmlfZGV2LCBibG9jaywg
YnVmc2l6ZSwgDQorCQkJCSAgICBmaWxwLT5mX3BvcywgDQorCQkJCSAgICBp
bm9kZS0+aV9zaXplKTsNCisJCQlpZiAoIWJoKQ0KKwkJICAgICAgICB7DQor
I2lmZGVmIERFQlVHDQorICAgICAgICAgICAgICAgICAJCXByaW50aygiIWJo
IGJsb2NrPSVsZCwgYnVmc2l6ZT0lbGRcbiIsYmxvY2ssYnVmc2l6ZSk7IA0K
KyAJCQkJcHJpbnRrKCJmaWxwLT5mX3BvcyA9ICVsZFxuIixmaWxwLT5mX3Bv
cyk7DQorCQkJCXByaW50aygiaW5vZGUtPmlfc2l6ZSA9ICVsZFxuIiwgaW5v
ZGUtPmlfc2l6ZSk7DQorI2VuZGlmDQorCQkJCXJldHVybiAwOw0KKwkJCX0N
CisJCSAgDQorCQkJbWVtY3B5KGJ1ZnNpemUgLSBvZmZzZXQgKyAoY2hhciAq
KSB0bXBkZSwgYmgtPmJfZGF0YSwgbmV4dF9vZmZzZXQpOw0KKwkJCWRlID0g
dG1wZGU7DQogCQl9DQorCQlvZmZzZXQgPSBuZXh0X29mZnNldDsNCiANCiAJ
CWlmKGRlLT5mbGFnc1staGlnaF9zaWVycmFdICYgMHg4MCkgew0KIAkJCWZp
cnN0X2RlID0gMDsNCg==
---559023410-851401618-941043792=:1561--

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/