rm -R * ... "illegal byte sequence"
MZ
gives me the error "illegal byte sequence". How do I get rid of these
files?
SS
You probably tried this already, but I have to suggest this just to be
on the safe side:
Did you try "rm -rf *"? The -f means "force" and is a bit more brutal,
but should be used with caution as it will delete just about everything
(even stuff you might not want to delete, if you're not careful).
I still remember the good old days when you'd see Linux-newbs asking on
IRC "How do I..." and they would get the reply "Just type 'sudo rm -rf
/' and enter the root password".
SS
MZ
Yeah, I've tried rm -rf and it still returns the same error.
Tim Daneliuk
I've never seen that error, but I wonder if it has something to do with
the file names you're trying to get rid of. It may be that rm is interpreting
them as args or something. Try this:
rm -rf -- dir
Otherwise these feels like some kind of Unicode silliness...
--
----------------------------------------------------------------------------
Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/
MZ
> On 6/6/2010 5:53 PM, MZ wrote:
>> I'm trying to remove a directory, but some of the files remain and it
>> gives me the error "illegal byte sequence". How do I get rid of these
>> files?
>
> I've never seen that error, but I wonder if it has something to do with
> the file names you're trying to get rid of. It may be that rm is interpreting
> them as args or something. Try this:
>
> rm -rf -- dir
>
> Otherwise these feels like some kind of Unicode silliness...
>
Same error.
I don't know if it's worth mentioning, but this folder was the /usr
directory copied onto FreeBSD 8 from a FreeBSD 7.2 install. The
specific problem directory is usr/local/lib/gcc-4.3.4/ ...
Bob Melson
Can you cd into the directory? If so, do that, then "rm -rf *". If
_that_ completes without error, "cd ..;rm -rf <your_directory_name>. If
it _doesn't_ complete without error and there are sub-directories, cd into
each of _them_ and do the rm -rf business for each.
Doesn't sound to me like there's an easier way to solve your problem.
Bob
--
Robert G. Melson | Rio Grande MicroSolutions | El Paso, Texas
-----
Nothing astonishes men so much as common sense and plain dealing.
Ralph Waldo Emerson
MZ
> On Sunday 06 June 2010 18:39, MZ (ma...@nospam.void) opined:
>
>> Tim Daneliuk wrote:
>>> On 6/6/2010 5:53 PM, MZ wrote:
>>>> I'm trying to remove a directory, but some of the files remain and it
>>>> gives me the error "illegal byte sequence". How do I get rid of these
>>>> files?
>>> I've never seen that error, but I wonder if it has something to do with
>>> the file names you're trying to get rid of. It may be that rm is
>>> interpreting
>>> them as args or something. Try this:
>>>
>>> rm -rf -- dir
>>>
>>> Otherwise these feels like some kind of Unicode silliness...
>>>
>> Same error.
>>
>> I don't know if it's worth mentioning, but this folder was the /usr
>> directory copied onto FreeBSD 8 from a FreeBSD 7.2 install. The
>> specific problem directory is usr/local/lib/gcc-4.3.4/ ...
>
> Can you cd into the directory? If so, do that, then "rm -rf *". If
> _that_ completes without error, "cd ..;rm -rf <your_directory_name>. If
> it _doesn't_ complete without error and there are sub-directories, cd into
> each of _them_ and do the rm -rf business for each.
>
> Doesn't sound to me like there's an easier way to solve your problem.
>
> Bob
>
I go all the way until I reach a group of files. I type "rm -rf *", and
it returns "no match". I type ls and it shows me the filenames. I type
ls -l and I get "illegal byte sequence" corresponding to each file.
# rm -rf "CupsIppOperation.h"
rm: CupsIppOperation.h: Illegal byte sequence
Bob Melson
Hmmm. Sounds like, maybe, file system corruption, if not what somebody
else suggested: some sort of posix lunacy. Only thing i can think of
to - maybe - fix it is to go to single user mode, unmount the offending
filesystem, fsck it, remount it, then try again to delete the directory
and files in question. I don't know that this'll work - or even that the
problem IS a corrupt file system. So far as I know, there should be no
problem mounting a 7.X filesystem on 8.X, but ...
Ted Nolan <tednolan>
And then there's always "clri" + fsck
Ted
--
------
columbiaclosings.com
What's not in Columbia anymore..
Indi
>
> # rm -rf "CupsIppOperation.h"
> rm: CupsIppOperation.h: Illegal byte sequence
chflags?
--
Caveat utilitor,
indi
Tim Daneliuk
OK, you might try a bulk renaming operation to rename them to
something you CAN delete. As it happens (he said modestly),
I have written exactly something like that:
http://www.tundraware.com/Software/tren/
You'll need Python 2.6 or later on your system to use it. In this
case, what you'll need to do is go to each directory in question
and use 'tren' to rename things to some random string. Try something
like this:
tren.py -r=/RAND100/ -- *
At this point, every file in the current directory will be renamed to a
string of 100 (quasi)random numeric characters. These *should* be
rm-able but I don't guarantee it...
MZ
It's a zfs volume, so I dont think it can be fsck'd.
Bob Eager
Get the inode number for the directory, and clri(8) it? Then fsck.
Drastic, but worked for me...even back on v6.
--
Using UNIX since v6 (1976)...
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
David Malone
"Illegal byte sequence" sounds like a locale related error. You could
try clearing running rm with a clear environment:
env - rm -fr -- directory
David.
Mike Clarke
> On Sun, 06 Jun 2010 20:39:10 -0400, MZ wrote:
>
>> Tim Daneliuk wrote:
>>> On 6/6/2010 5:53 PM, MZ wrote:
>>>> I'm trying to remove a directory, but some of the files remain and it
>>>> gives me the error "illegal byte sequence". How do I get rid of these
>>>> files?
[snip]
>> I don't know if it's worth mentioning, but this folder was the /usr
>> directory copied onto FreeBSD 8 from a FreeBSD 7.2 install. The
>> specific problem directory is usr/local/lib/gcc-4.3.4/ ...
>
> Get the inode number for the directory, and clri(8) it? Then fsck.
>
> Drastic, but worked for me...even back on v6.
Having got the inode number this might work, but only for deleting a single
file at a time ...
find . -inum nnnn -delete
or, more cautiously
find . -inum nnnn -ok rm {} \;
... this approach has often got me out of a hole when dealing
with "impossible" file names.
--
Mike Clarke
Bob Eager
I was thinking of ls -id on the directory, then zap that.
Harald Hanche-Olsen
> It's a zfs volume, so I dont think it can be fsck'd.
That is important information. You should have told us from the start!
Then you wouldn't have wasted so much of other people's time.
My two cents worth: Try booting the system into opensolaris and try
deleting the files from there. Or try poking around in the archives of
the freebsd-fs mailing list or ask on that list, or find some other zfs
related mailing list.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
MZ
> + MZ <ma...@nospam.void>:
>
>> It's a zfs volume, so I dont think it can be fsck'd.
>
> That is important information. You should have told us from the start!
> Then you wouldn't have wasted so much of other people's time.
>
> My two cents worth: Try booting the system into opensolaris and try
> deleting the files from there. Or try poking around in the archives of
> the freebsd-fs mailing list or ask on that list, or find some other zfs
> related mailing list.
I haven't the foggiest idea about how to boot into opensolaris...
MZ
Still returns illegal byte sequence.
MZ
Still returns illegal byte sequence.
# env - rm -fr -- local
rm: local/lib/gcc-4.3.4/include/c++/gnu/javax/imageio: Illegal byte sequence
rm: local/lib/gcc-4.3.4/include/c++/gnu/javax/print/PrinterDialog.h:
Illegal byt
e sequence
rm:
local/lib/gcc-4.3.4/include/c++/gnu/javax/print/PrintFlavorException.h: Ille
gal byte sequence
rm:
local/lib/gcc-4.3.4/include/c++/gnu/javax/print/PrintAttributeException.h: I
llegal byte sequence
rm: local/lib/gcc-4.3.4/include/c++/gnu/javax/print/CupsIppOperation.h:
Illegal
byte sequence
rm:
local/lib/gcc-4.3.4/include/c++/gnu/javax/print/CupsPrintServiceLookup.h: Il
legal byte sequence
rm: local/lib/gcc-4.3.4/include/c++/gnu/javax/print/CupsPrintService.h:
Illegal
byte sequence
rm: local/lib/gcc-4.3.4/include/c++/gnu/javax/print/PrintUriException.h:
Illegal
byte sequence
rm: local/lib/gcc-4.3.4/include/c++/gnu/javax/print/CupsServer.h:
Illegal byte s
equence
rm: local/lib/gcc-4.3.4/include/c++/gnu/javax/print: Directory not empty
rm: local/lib/gcc-4.3.4/include/c++/gnu/javax: Directory not empty
rm: local/lib/gcc-4.3.4/include/c++/gnu: Directory not empty
rm: local/lib/gcc-4.3.4/include/c++: Directory not empty
rm: local/lib/gcc-4.3.4/include: Directory not empty
rm: local/lib/gcc-4.3.4: Directory not empty
rm: local/lib: Directory not empty
rm: local: Directory not empty
David Malone
>Still returns illegal byte sequence.
Hmmm - odd - "Illegal byte sequence" is definitely a locale related
error, it's listed as EILSEQ in errno(2) and should usually only
happen if you're using multibyte or wide characters. The multibyte
stuff changes the behaviour of quite a number of library functions
that deal with strings, so it is hard to guess exactly where the
problem is. If you use "rm" directly on one of the files, rather
than "rm -r ..." do you see the same problem? How about using unlink?
David.
MZ
# ls
CupsIppOperation.h PrintAttributeException.h
CupsPrintService.h PrintFlavorException.h
CupsPrintServiceLookup.h PrintUriException.h
CupsServer.h PrinterDialog.h
# unlink PrinterDialog.h
unlink: PrinterDialog.h: Illegal byte sequence
# rm PrinterDialog.h
rm: PrinterDialog.h: Illegal byte sequence
Tim Daneliuk
This was my original suspicion as well. Have you tried to go to
a clean (non Unicode) locale and simply rename a file to see if
you can then delete it?
Bob Eager
ls -i PrinterDialog.h
(get inode number on left)
use clri to clear it (on the correct device!)
fsck the device
MZ
> MZ wrote:
>
>> David Malone wrote:
>>> MZ <ma...@nospam.void> writes:
>
>>>> Still returns illegal byte sequence.
>
>>> Hmmm - odd - "Illegal byte sequence" is definitely a locale related
>>> error, it's listed as EILSEQ in errno(2) and should usually only
>>> happen if you're using multibyte or wide characters. The multibyte
>>> stuff changes the behaviour of quite a number of library functions
>>> that deal with strings, so it is hard to guess exactly where the
>>> problem is. If you use "rm" directly on one of the files, rather
>>> than "rm -r ..." do you see the same problem? How about using unlink?
>
>> CupsIppOperation.h PrintAttributeException.h
>> CupsPrintService.h PrintFlavorException.h
>> CupsPrintServiceLookup.h PrintUriException.h
>> CupsServer.h PrinterDialog.h
>> # unlink PrinterDialog.h
>> unlink: PrinterDialog.h: Illegal byte sequence
>> # rm PrinterDialog.h
>> rm: PrinterDialog.h: Illegal byte sequence
>
> same directory what is the output of "ls -lo" ?
>
# ls -lo
ls: CupsIppOperation.h: Illegal byte sequence
ls: CupsPrintService.h: Illegal byte sequence
ls: CupsPrintServiceLookup.h: Illegal byte sequence
ls: CupsServer.h: Illegal byte sequence
ls: PrintAttributeException.h: Illegal byte sequence
ls: PrintFlavorException.h: Illegal byte sequence
ls: PrintUriException.h: Illegal byte sequence
ls: PrinterDialog.h: Illegal byte sequence
total 0
MZ
# ls -i PrinterDialog.h
ls: PrinterDialog.h: Illegal byte sequence
Also, I don't believe I can fsck the device, because it's a zfs raidz
array. But I'll research this some more.
MZ
Interesting. I haven't tried that. How do I go to a clean locale?
Tim Daneliuk
What is output on your system of:
locale
Let's see where you are right now.
MZ
# locale
LANG=
LC_CTYPE="C"
LC_COLLATE="C"
LC_TIME="C"
LC_NUMERIC="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_ALL=
Paul Floyd
Tim Daneliuk
(One stupid question first here ... you ARE doing this as root, right? Or at least as
a user with permission to delete these files???)
OK, that's all normal default. Try going to one of the directories in question and doing
this:
for x in *
do
mv $x TEST
done
If this works, you'll end up with one file called "TEST" at the end (assuming there were no
dot files) which you should then be able to rm.
If this does not work, you have other problems. Someone has already suggested you
look into the flags of each file and change them as necessary to make them deletable
(use chflags to change them).
Another way might be to boot the recovery DVD, go into the recovery shell, and manually
mount the filesystem with the painful files on it to see if you can delete them from
that environment.
Failing this, I am clueless unless you have a bad disk, filesystem, or failing hardware
of some kind. Are you SURE you've fsck-ed the filesystem? Are you SURE you have good,
working hardware?
Tim Daneliuk
Yup. I just grepped the code and EILSEQ shows up all over the place
in the locale and nls code.
HOWEVER, a corrupted file system could cause this by creating the
appearance of multibyte chars in file names and/or corrupting
the rm command itself. Naturally, a "corrupted file system" could
happen for a number of reasons, the most likely being hardware-related
like flaky memory and/or disk and/or mobo/disk controller.
MZ
Yeah, root.
> OK, that's all normal default. Try going to one of the directories in question and doing
> this:
>
> for x in *
> do
> mv $x TEST
> done
>
> If this works, you'll end up with one file called "TEST" at the end (assuming there were no
> dot files) which you should then be able to rm.
The problem seems to be that it doesn't like wildcards. It has to then
represent the filenames, which it's not able to do. If I could get the
inodes of these files, then I could reference them that way and probably
get this thing to work. Does anyone know of a way to retrieve the
inodes without actually specifying the filenames?
> If this does not work, you have other problems. Someone has already suggested you
> look into the flags of each file and change them as necessary to make them deletable
> (use chflags to change them).
chflags doesn't work because I have to reference the files by name.
> Another way might be to boot the recovery DVD, go into the recovery shell, and manually
> mount the filesystem with the painful files on it to see if you can delete them from
> that environment.
Wouldn't I then run into the same problem? Referring to the files by
name...
> Failing this, I am clueless unless you have a bad disk, filesystem, or failing hardware
> of some kind. Are you SURE you've fsck-ed the filesystem? Are you SURE you have good,
> working hardware?
Well, I can't be sure, but there are no other signs of bad anything.
These are fairly new (~1yr) 1TB drives.
Although it's possible that they were corrupted somehow from the getgo,
maybe during the copy process from the old drive to the new ones?
MZ
> filenames to be in utf8, rather than just be sequences of bytes.
> I don't know a lot about this, but turning on/off the "utf8only"
> properity on your zfs might help.
I will look into this. Thanks!