Re: [9fans] kfs un-removable file

[rog@vitanuova.com]

> I doubt that.  C2 80 is UTF for 0x80, the error rune.
> When any of the UTF routines process a bad UTF sequence, they
> replace it with the error rune.  So what's really happening,
> probably, is that kfs is giving you bad data (not UTF) and
> ls is coping.

that's not necessarily the case.

we've got some files on our filesystem (an old style fileserver) that
have C2 80 sequences in them, and they seem to be unremovable.  a
direct stat on the files still gives the c2-80 sequences (as far as i
can see convM2D doesn't do any utf conversions, so it shouldn't be
necessary to look at the raw dir format)

not only are the files non-removable, several of them have a few
duplicates.

after a little experimentation, it seems that the fileserver (and
presumably kfs too) doesn't check utf consistency on input, but does
convert utf chars on output (mind you, it's not obvious from a quick
check in the source).

in fact, in the example i just tried, i did similar to:

	char buf[] = "/tmp/yyXz";
	buf[7] = 0xff; create(buf, OWRITE, 8r666);
	buf[7] = 0xfd; create(buf, OWRITE, 8r666);

both creates succeeded, and i now have two unremovable
files in my /tmp (oops).

cat /tmp | xd -c

shows that the filenames of each are identical (in this
case they're each exactly "yy").

i'd suggest that perhaps it'd be a good idea for the fileserver
to canonicalise names on creation as quite apart from
invalid utf sequences, aren't there several possible
utf sequences that can validly map to the same character?