rm -R * ... "illegal byte sequence"
in [FreeBSD]
|
From: Tim Daneliuk on 7 Jun 2010 16:10 On 6/7/2010 2:53 PM, MZ wrote: > Tim Daneliuk wrote: >> On 6/7/2010 1:42 PM, MZ wrote: >>> Tim Daneliuk wrote: >>>> On 6/7/2010 12:27 PM, MZ wrote: >>>>> David Malone wrote: >>>>>> MZ <mark(a)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? >>>>>> >>>>>> David. >>>>> # 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 >>>> 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? >>>> >>> Interesting. I haven't tried that. How do I go to a clean locale? >> >> What is output on your system of: >> >> locale >> >> Let's see where you are right now. > > # locale > LANG= > LC_CTYPE="C" > LC_COLLATE="C" > LC_TIME="C" > LC_NUMERIC="C" > LC_MONETARY="C" > LC_MESSAGES="C" > LC_ALL= (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 tundra(a)tundraware.com PGP Key: http://www.tundraware.com/PGP/
From: Tim Daneliuk on 7 Jun 2010 16:20 On 6/7/2010 11:57 AM, David Malone wrote: > MZ <mark(a)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? > > David. 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. -- ---------------------------------------------------------------------------- Tim Daneliuk tundra(a)tundraware.com PGP Key: http://www.tundraware.com/PGP/
From: David Malone on 7 Jun 2010 16:28 MZ <mark(a)nospam.void> writes: >Also, I don't believe I can fsck the device, because it's a zfs raidz >array. But I'll research this some more. Ah - now we're talking! It seems that zfs can be told to consider 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. David.
From: MZ on 7 Jun 2010 16:50 Tim Daneliuk wrote: > On 6/7/2010 2:53 PM, MZ wrote: >> Tim Daneliuk wrote: >>> On 6/7/2010 1:42 PM, MZ wrote: >>>> Tim Daneliuk wrote: >>>>> On 6/7/2010 12:27 PM, MZ wrote: >>>>>> David Malone wrote: >>>>>>> MZ <mark(a)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? >>>>>>> >>>>>>> David. >>>>>> # 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 >>>>> 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? >>>>> >>>> Interesting. I haven't tried that. How do I go to a clean locale? >>> What is output on your system of: >>> >>> locale >>> >>> Let's see where you are right now. >> # locale >> LANG= >> LC_CTYPE="C" >> LC_COLLATE="C" >> LC_TIME="C" >> LC_NUMERIC="C" >> LC_MONETARY="C" >> LC_MESSAGES="C" >> LC_ALL= > > (One stupid question first here ... you ARE doing this as root, right? Or at least as > a user with permission to delete these files???) 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?
From: MZ on 7 Jun 2010 16:52 David Malone wrote: > MZ <mark(a)nospam.void> writes: > >> Also, I don't believe I can fsck the device, because it's a zfs raidz >> array. But I'll research this some more. > > Ah - now we're talking! It seems that zfs can be told to consider > 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!
First
|
Prev
|
Pages: 1 2 3 4 5 6 Prev: OpenTTD From Gnome? Next: NYC LOCAL: Tuesday 8 June 2010 Lisp NYC Meet and NYLUG Hack Meet |