Re: [9fans] Weirdness with 9660srv and file names (extensions)?

Re: [9fans] Weirdness with 9660srv and file names (extensions)?

[Russ Cox]

> ITYM "VMS heads"...

Changed, thanks.  I'm happy not to know anything about VMS.

Re: [9fans] Weirdness with 9660srv and file names (extensions)?

[William S.]

What are some of the things you like. Sometime in the
near future I hope to be running VMS on a MicroVAX II,
MicroVAX 3100-30 and VAXstation 2000.

Bill
Amsterdam, NL

On Mon, Jan 28, 2002 at 06:23:29PM -0500, Dan Cross wrote:
> Sounds just fine to me.  Thanks, Russ.
>
> btw- there are things about VMS that I like.
>

Re: [9fans] Weirdness with 9660srv and file names (extensions)?

[Dan Cross]

Sounds just fine to me.  Thanks, Russ.

	- Dan C.

btw- there are things about VMS that I like.

Re: [9fans] Weirdness with 9660srv and file names (extensions)?

[Boyd Roberts]

Alexander Viro wrote:
> >                        * (DOS heads couldn't comprehend the dot as a file name character
>
> ITYM "VMS heads"...

Goes back further than that;  RSTS (iirc) and RSX?

Re: [9fans] Weirdness with 9660srv and file names (extensions)?

[Alexander Viro]

On Sun, 27 Jan 2002, Russ Cox wrote:

> 			 * (DOS heads couldn't comprehend the dot as a file name character


ITYM "VMS heads"...

Re: [9fans] Weirdness with 9660srv and file names (extensions)?

[Russ Cox]

The ISO9660 spec (actually I was reading ECMA 119, which
is supposedly identical) is fairly clear about this issue:
every file on the volume should have a . and a ; in
its name, since they are separators rather than file
name characters.  That is, every name is supposed to
be of the form

	file name . file extension ; version

Most writers (including our very own mk9660) don't
put the . and ; in when there is nothing to separate,
so our mishandling of the trailing . hadn't been
noticed before.

Thus I propose replacing

		p = strchr(d->name, ';');
		if(p != 0) {
			vers = strtoul(p+1, 0, 10);
			memset(p, 0, NAMELEN-(p-d->name));
		}

with

		if(fmt!='9' && !(d->mode&CHDIR)){
			/*
			 * ISO 9660 actually requires that you always have a . and a ;,
			 * even if there is no version and no extension.  Very few writers
			 * do this.  If the version is present, we use it for qid.vers.
			 * If there is no extension but there is a dot, we strip it off.
			 * (DOS heads couldn't comprehend the dot as a file name character
			 * rather than as just a separator between name and extension.)
			 *
			 * We don't do this for directory names because directories are
			 * not allowed to have extensions and versions.
			 */
			if((p=strchr(d->name, ';')) != nil){
				vers = strtoul(p+1, 0, 0);
				d->qid.vers = vers;
				memset(p, 0, NAMELEN-(p-d->name));
			}
			if((p=strchr(d->name, '.')) != nil && *(p+1)=='\0')
				memset(p, 0, NAMELEN-(p-d->name));
		}

Russ

Re: [9fans] Weirdness with 9660srv and file names (extensions)?

[Dan Cross]

Thanks for the info, Charles.  Yes, this was the June 2000 Inferno CD (who
should I send mail to get to an update CD, btw?).

Anyway, I did some more research, and here are my results:

	+ The CSRG BSD Unix archive, CD 2, uses RockRidge and has
	  the trailing dot
	+ The VN Inferno CD says is using Joliet, and has the dot.
	+ The VN Plan 9 CD is fine
	+ The OpenBSD 2.6 CD uses RockRidge but seems okay

The following patch to /sys/src/cmd/9660srv/9660srv.c seems to fix the
problem:

----  Begin
656,658d655
< 			if (!(d->mode & CHDIR) && *(p - 1) == '.') {
< 				*(p - 1) = 0;
< 			}
----  End

But I confess ignorance when it comes to CD directory structures, so it's
possible it's incorrect.

	- Dan C.

Re: [9fans] Weirdness with 9660srv and file names (extensions)?

[Boyd Roberts]

bs wrote:
>
> I have seen this happen on a lot Unix systems too when I read
> a CD burned by Adaptec CD burner s/w on a Windows system and the
> file does not have an extension.

Happened to me the other night.  It decided that there was a file
called .DOT and it really didn't like that.  I think it had got
confused over /usr/boyd/. or something, so I just renamed it to
be x.DOT.

Much as dd's syntax is gross, it does not ask you stupid questions.

Re: [9fans] Weirdness with 9660srv and file names (extensions)?

[bs]

I have seen this happen on a lot Unix systems too when I read
a CD burned by Adaptec CD burner s/w on a Windows system and the
file does not have an extension.

Dan Cross wrote:
>
> Has anyone ever seen 9660srv interpret filenames such that it appends a
> dot (.) to names that doesn't have an extension?  Eg, I'm getting something
> like the following:
>
> term% 9660srv
> term% mount /srv/9660 /mnt/cd /dev/sdD0/data
> term% cd /mnt/cd
> term% ls
> readme.
> foo.txt
> bin
> term% cd
> term% unmount /mnt/cd
>
> Note that ``readme.'' should really be ``readme'', sans terminating
> period.
>
> I hacked the directory reading functions in 9660srv to `fix' this, but
> I can't help feeling that I'm missing something subtle, or that this is
> something already encountered and squished.
>
>         - Dan C.

Re: [9fans] Weirdness with 9660srv and file names (extensions)?

[forsyth]

[-- Attachment #1: Type: text/plain, Size: 2370 bytes --]

>>Shucks, I left my laptop at home this morning, so I'm afraid I can't
>>tell definitively at the moment, but the problem showed up trying to
>>read the VN Inferno CD, among others.  The file is most definitely
>>*not* named ``readme.''; the periods don't show up under other OS's
>>(I've tried Windows and FreeBSD), and the Inferno installation script
>>failed when it couldn't find, eg, ``foo'' because ``foo'' was known
>>as ``foo.''.  Not what VN had intended, I'm guessing.

i missed the initial message that prompted this discussion, so i don't
know the receiving system.

it does sound like a problem with the reading software, but it might help
to know that the July 2000 Inferno CD (the first one) was written using some ghastly
Windows software because the Plan 9 code at the time produced incorrect
results and we didn't have time to investigate.   the June 2001 Inferno CD and
all our Plan 9 CDs were written using Plan 9, but using a modified version
of the june 2000 disk/mk9660.  the modifications were to several two bugs
in the output format, and to change the publisher names and dates.
It uses Joliet format to record long, mixed-case names, but for
the benefit of commercial Unix systems that don't support Joliet,
it writes mixed-case names in the 9660 name section.  thus, it isn't
strictly conforming at some Level of the 9660 standard.  the commercial
Unix systems that I tried had no trouble with it.  Solaris needs
a special option when mounting or it maps the names to lower case anyway.
(xBSD/Linux read the names from the Joliet section, as did NT).
I didn't use Rock Ridge for the benefit of the Unix systems because
Windows couldn't cope.  I didn't write Rock Ridge and Joliet because
the writing software that could do that had some problem or restriction
that prevented it.  I don't remember what that was but no doubt
when I do the next ones I'll find it out again.

the Plan 9 CD isn't bootable because although I could write the boot format
correctly, and boot from it, because I'd have needed either to put
9660 support in the bootstrap.  I've done that before on PowerPC platforms
for Inferno, but it makes the bootstrap bigger and more complicated.
On the PC, because of the way the BIOS does CD bootstraps, a little hack
would suffice but I hadn't time to sort it out last time.
next time.


[-- Attachment #2: Type: message/rfc822, Size: 2665 bytes --]

To: 9fans@cse.psu.edu
Subject: Re: [9fans] Weirdness with 9660srv and file names (extensions)?
Date: Thu, 24 Jan 2002 16:53:47 -0500
Message-ID: <200201242153.QAA15132@math.psu.edu>

> ls -l /mnt/cd
>
> the owner/group will tell you what sort
> of format the cd is.  that'd be a start.
>
> if it's iso9660 or joliet or plan9, i'm stumped.
>
> if it's ridge or sierra, we might be parsing things
> wrong, or the file might really be named ``readme.''

Shucks, I left my laptop at home this morning, so I'm afraid I can't
tell definitively at the moment, but the problem showed up trying to
read the VN Inferno CD, among others.  The file is most definitely
*not* named ``readme.''; the periods don't show up under other OS's
(I've tried Windows and FreeBSD), and the Inferno installation script
failed when it couldn't find, eg, ``foo'' because ``foo'' was known
as ``foo.''.  Not what VN had intended, I'm guessing.

(this is from memory)  I did modify a routine, called, I believe,
rzdir() in 9660srv.c to remove trailing dots from file names shortly
after a section of code in which file version numbers were being
stripped off.  That seemed to fix at least some of it; it strikes me
that was using a strict iso9660 CD.

	- Dan C.

Re: [9fans] Weirdness with 9660srv and file names (extensions)?

[Dan Cross]

> ls -l /mnt/cd
>
> the owner/group will tell you what sort
> of format the cd is.  that'd be a start.
>
> if it's iso9660 or joliet or plan9, i'm stumped.
>
> if it's ridge or sierra, we might be parsing things
> wrong, or the file might really be named ``readme.''

Shucks, I left my laptop at home this morning, so I'm afraid I can't
tell definitively at the moment, but the problem showed up trying to
read the VN Inferno CD, among others.  The file is most definitely
*not* named ``readme.''; the periods don't show up under other OS's
(I've tried Windows and FreeBSD), and the Inferno installation script
failed when it couldn't find, eg, ``foo'' because ``foo'' was known
as ``foo.''.  Not what VN had intended, I'm guessing.

(this is from memory)  I did modify a routine, called, I believe,
rzdir() in 9660srv.c to remove trailing dots from file names shortly
after a section of code in which file version numbers were being
stripped off.  That seemed to fix at least some of it; it strikes me
that was using a strict iso9660 CD.

	- Dan C.

Re: [9fans] Weirdness with 9660srv and file names (extensions)?

[Boyd Roberts]

Russ Cox wrote:
> 9660 requires 8.3 format.  There are various extensions
> that don't.

Oh, I was assuming (from all the 9660's I've seen) that
such extensions were the default.  Anyway, I hate that
adaptec s/w.

Assumption being the mother of all ...

Re: [9fans] Weirdness with 9660srv and file names (extensions)?

[Russ Cox]

> My stupid adaptec CD burning s/w mangles the names to
> Windows short names, even though you specified 9660.

9660 requires 8.3 format.  There are various extensions
that don't.  You need to turn on the use of Rock Ridge or
Joliet extensions.  (Or Plan 9 extensions, but I assume that's
not an option.)

Russ

Re: [9fans] Weirdness with 9660srv and file names (extensions)?

[Boyd Roberts]

My stupid adaptec CD burning s/w mangles the names to
Windows short names, even though you specified 9660.

I tripped across this gem when backing up the python2.2
port [9P2000 -> 9P release 3].

Re: [9fans] Weirdness with 9660srv and file names (extensions)?

[Russ Cox]

ls -l /mnt/cd

the owner/group will tell you what sort
of format the cd is.  that'd be a start.

if it's iso9660 or joliet or plan9, i'm stumped.

if it's ridge or sierra, we might be parsing things
wrong, or the file might really be named ``readme.''

[9fans] Weirdness with 9660srv and file names (extensions)?

[Dan Cross]

Has anyone ever seen 9660srv interpret filenames such that it appends a
dot (.) to names that doesn't have an extension?  Eg, I'm getting something
like the following:

term% 9660srv
term% mount /srv/9660 /mnt/cd /dev/sdD0/data
term% cd /mnt/cd
term% ls
readme.
foo.txt
bin
term% cd
term% unmount /mnt/cd

Note that ``readme.'' should really be ``readme'', sans terminating
period.

I hacked the directory reading functions in 9660srv to `fix' this, but
I can't help feeling that I'm missing something subtle, or that this is
something already encountered and squished.

	- Dan C.