[vox-tech] Removing Files

[Ken Herron]

--On Friday, May 21, 2004 11:48:16 +0000 Tim Riley=20
<timriley@timriley.net> wrote:

>> <snip>
>> > r =3D 114
>> > =B4 =3D 4294967220
>
> This character is suspicious. It's supposed to be 39, so
> apparently there are colors or other attribute information
> embedded.

The actual character code is 180 decimal, which is an acute accent in the =

latin1 (or ISO8859-1) character set. You're getting 4294967220 because of =

a bug in the program. ptr points to signed characters so 180 is=20
interpreted as -76; when *ptr is passed to printf(), the value is=20
sign-extended to a signed int and then printed as if it were unsigned.

But none of this really matters. When you get a filename from readdir(),=20
you should be able to call unlink() on that string and refer to the same=20
file. Funny high-bit characters in the string shouldn't be an issue at=20
this level. Certainly running "rm -r" on the directory containing the=20
file should have worked.

Daniel, the test program you posted actually copies the filename string=20
into another buffer usint sprintf(). I don't think *printf() is supposed=20
to do character-set conversions, but maybe it does. Try using strcat() to =

construct the pathname for deletion, or else just chdir() into the=20
directory containing the file and call unlink() on the contents of the=20
d_name buffer.

If this doesn't work, then it seems to me you have filesystem corruption, =

despite the fact that fsck didn't find anything to fix. You might have to =

resort to something drastic like:

1) Become root.
2) Unlink the directory containing the file (see rm's "-d" or=20
"--directory" option).
3) Unmount the filesystem and fsck it.

--=20
"Grand Funk Railroad paved the way for Jefferson Airplane, which cleared
the way for Jefferson Starship. The stage was now set for the Alan =
Parsons
Project, which I believe was some sort of hovercraft." - Homer Simpson

Kenneth Herron     Kenneth.Herron@mci.com     v658-5894     916-569-5894