[9fans] kfs un-removable file

[9fans] kfs un-removable file

[steve-simon]

Hi,

Maybe I should just ignore this but I have managed to
create a file that I cannot remove (under kfs).

I have tried 
	disk/kfscmd 'remove /usr/steve/work/pcp/e€€B'
and 
	disk/kfscmd 'clri /usr/steve/work/pcp/e€€B'
but both of them error with "can't walk e€€B"

NB the above where cut and paste so the runes are correct.

term% ls -lq
(000000000000f6c5 1 00) --rw-r--r-- M 8 steve steve 0 Sep 18 12:56 e€€B
term% ls | xd -c
0000000   e c2 80 c2 80  B \n
0000007 


Anyone any ideas how I can get rid of this file?

-Steve

Re: [9fans] kfs un-removable file

[Russ Cox]

> Maybe I should just ignore this but I have managed to
> create a file that I cannot remove (under kfs).
>
> I have tried
> 	disk/kfscmd 'remove /usr/steve/work/pcp/e=C2=80=C2=80B'
> and=
> 	disk/kfscmd 'clri /usr/steve/work/pcp/e=C2=80=C2=80B'
> but both of them error with "can't walk e=C2=80=C2=80B"
>
> NB the above where cut and paste so the runes are correct.

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.

If you write a program to walk through the directory manually
and call remove on the offending file, you should be fine.
Just avoid all the utf routines (like print!).

Of course, kfs might check that names you give it are okay
UTF, but off the top of my head I don't think it does.

Russ

Re: [9fans] kfs un-removable file

[C H Forsyth]

>>If you write a program to walk through the directory manually
>>and call remove on the offending file, you should be fine.
>>Just avoid all the utf routines (like print!).

be sure to call it `dsw'

Re: [9fans] kfs un-removable file

[ron minnich]

On Mon, 27 Oct 2003, C H Forsyth wrote:

> >>If you write a program to walk through the directory manually
> >>and call remove on the offending file, you should be fine.
> >>Just avoid all the utf routines (like print!).
>
> be sure to call it `dsw'
>

I think I might build a USB interface to my old PDP 11/45 front panel.
Then, I can have dsw read the switches.

Oh, shucks, no inumbers! But FIDS are still 16 bits, right? no problem!

ron

Re: [9fans] kfs un-removable file

[rog]

> 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?

Re: [9fans] kfs un-removable file

[Scott Schwartz]

| invalid utf sequences, aren't there several possible
| utf sequences that can validly map to the same character?

I think only the shortest such sequence is supposed to be allowed, so
maybe calling it an error is better than canonicalizing.  On the other
hand, Tcl uses a multibyte encoding of \0 to handle embedded nuls.
That seems like a useful hack.