Can't delete file with strange name

try something like this
Code:
#!/usr/bin/perl
unlink "\x{4156}\x{0069}\x{0076}\x{0069}\x{0061}\x{000f}\x{00bc}\x{6e00}\x{23f0}\x{3300}";
 
or
Code:
#!/usr/bin/perl
opendir(CURRENT_DIR, ".") or die "ERR: can't read dircetory: '$item'.\n$1\n";
my @content = readdir CURRENT_DIR;
closedir(CURRENT_DIR);
foreach my $i (2 .. $#content) {
  unlink $i if ($i ~= m/\x{4156}\x{0069}\x{0076}.*/);
}
or more brutal:
Code:
#!/usr/bin/perl
opendir(CURRENT_DIR, ".") or die "ERR: can't read dircetory: '$item'.\n$1\n";
my @content = readdir CURRENT_DIR;
closedir(CURRENT_DIR);
foreach my $i (2 .. $#content) {
  unlink $i or warn "WARN: Unable to rm $i";
}
be sure to backup data, as I haven't tested this script [should work however]
and execute in same dir as that file

another crazy idea: [not sure if hex editor will allow you to, but worth trying. Folders are basically files. Actually everything is file in unix]:
using some hex editor and simply open folder as with hd, and edit filename to common sense (should end with 0), But be extra careful
 
kdulep said:
use KISS principle and use misc/mc port to delete it?
xD

That may work. However, I already tried konqueror as file manager, and it does not see the file at all. Anyway, I installed mc, although not very successfully:

Code:
~ % mc
/libexec/ld-elf.so.1: /usr/local/bin/mc: Undefined symbol "g_malloc0_n"

I probably need to update my ports, but am reluctant to do that now after having been bitten by the jpeg update earlier this year. My machine was compiling for 3 days. x(

Thanks for the idea anyway!

fronclynne said:
copy or tar(1) everything else on the drive, format the drive, put everything else back.

That's probably what I will end up doing. Very drastic, but sure to get rid of the junk.
Thanks.

pprocacci said:
As killasmurf suggested, an fsck will most likely find and fix the problem. Normally I'd go on to suggest running a utility that doesn't depend on the shell globbing characters and whatnot but "rf -rf dir" would cover that. Do yourself a favor and fsck the drive.

I already did fsck, see results in post #21. What I haven't done yet is to use chkdsk /f on a Windows machine, as proposed by Beastie in post #28. Will try do do that today.
 
When you said in post #40 that you're still unable to remove the directory, does this include using the MacBook too?

On what OS was the directory first created? MacOS? Because using these characters -- " * / : < > ? \ | -- in a FAT filesystem is forbidden.
 
hi

another way to find the inode is

Code:
find . -ls

3988944        0 drwxr-xr-x    3 adz      staff         102  1 Jun 20:46 .
3988947        0 -rw-r--r--    1 adz      staff           0  1 Jun 20:46 ./test

where the inode is the number on the left. with regard to the ls -i command whats happening is that the ls cant process the input, but maybe find can?

/mgk
 
You may have luck using fsdb. Be very wary though, this utility has the opportunity of screwing things up royally. Do NOT mount the partition you want to work on....then:

Example:
Code:
fsdb /dev/ad0s1e   # Use your device
Last Mounted on /tmp
current inode: directory
I=2 MODE=41777 SIZE=1024
        BTIME=May  1 01:53:23 2009 [0 nsec]
        MTIME=Jun  2 18:46:29 2010 [0 nsec]
        CTIME=Jun  2 18:46:29 2010 [0 nsec]
        ATIME=Jun  2 18:48:46 2010 [0 nsec]
OWNER=root GRP=wheel LINKCNT=24 FLAGS=0 BLKCNT=4 GEN=38b32c1c
fsdb (inum: 2)> cd x
component `x': current inode: directory
I=16452 MODE=40755 SIZE=512
        BTIME=Jun  2 18:46:28 2010 [0 nsec]
        MTIME=Jun  2 18:46:38 2010 [0 nsec]
        CTIME=Jun  2 18:46:38 2010 [0 nsec]
        ATIME=Jun  2 18:47:53 2010 [0 nsec]
OWNER=root GRP=wheel LINKCNT=2 FLAGS=0 BLKCNT=4 GEN=fffffffff75b9986
fsdb (inum: 16452)> ls
slot 0 ino 16452 reclen 12: directory, `.'
slot 1 ino 2 reclen 12: directory, `..'
slot 2 ino 16457 reclen 488: regular, `Bla?h'
fsdb (inum: 16452)> clri 16457
fsdb (inum: 16452)> exit

Run:

fsck -y /dev/ad0s1e # or your device

Then mount.

Just a word of caution though, I've done this once before in the past, but don't remember if anything else needs to be done. fsdb did save my ass the one time however.

Edit: If that doesn't work, you can try removing the parent inode using the above as well, followed by an fsck.
Edit2: I honestly don't think the perl approach will work, but please try and let us know.
 
Compile this cc -o rfiles sourcefile.c
Run ./rfiles /your/path

PHP:
#include <sys/types.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <errno.h>
#include <dirent.h>
#include <assert.h>

/*Usage: app [path]*/

int main(int argc, char **argv){
	DIR *dir_h;
	struct dirent *dirn;
	char *path = NULL;
	
	if(argc == 1)
		return 1;
	
	if((dir_h = opendir(argv[1])) == NULL){
		perror("Error:");
		
		return 1;
	}
	
	while((dirn = readdir(dir_h)) != NULL){
		if(dirn->d_type != DT_DIR){
			asprintf(&path, "%s/%s", argv[1], dirn->d_name);
			assert(path != NULL);
			
			printf("Deleting '%s'.", path);
			
			if(remove(path) == -1){
				perror("\nError:");
			} else
				printf(" Done!\n");
			
			free(path);
		}
	}
	
	closedir(dir_h);
	
	return 0;	
}

If this fails its problem at the mount_msfs module.
 
killasmurf86 said:
or
Code:
#!/usr/bin/perl
opendir(CURRENT_DIR, ".") or die "ERR: can't read dircetory: '$item'.\n$1\n";
my @content = readdir CURRENT_DIR;
closedir(CURRENT_DIR);
foreach my $i (2 .. $#content) {
  unlink $i if ($i ~= m/\x{4156}\x{0069}\x{0076}.*/);
}
or more brutal:
Code:
#!/usr/bin/perl
opendir(CURRENT_DIR, ".") or die "ERR: can't read dircetory: '$item'.\n$1\n";
my @content = readdir CURRENT_DIR;
closedir(CURRENT_DIR);
foreach my $i (2 .. $#content) {
  unlink $i or warn "WARN: Unable to rm $i";
}
be sure to backup data, as I haven't tested this script [should work however]
and execute in same dir as that file

another crazy idea: [not sure if hex editor will allow you to, but worth trying. Folders are basically files. Actually everything is file in unix]:
using some hex editor and simply open folder as with hd, and edit filename to common sense (should end with 0), But be extra careful

Sorry for this late answer, but occasionally I am required to do some useful work during the day. Killasmurf, you are incredible! When I read your post suggesting a perl script, I turned around to grab my Camel and Cokbook from the bookshelf. When I turned back, you had already supplied three scripts. (Well, almost :) )

I copied your first script to file ~/viv_del.pl and did:

Code:
% ~/viv_del.pl
% ls
Vivian?3

Still there!

when inspecting your script I got the idea that maybe the A (41) should not be part of the name, so I modified the script and called it ~/viv_del1.pl:

Code:
% sdiff ~/viv_del.pl ~/viv_del1.pl
#!/usr/bin/perl                                                 #!/usr/bin/perl
unlink "\x{4156}\x{0069}\x{0076}\x{0069}\x{0061}\x{000f}\x{00 | unlink "\x{5600}\x{6900}\x{7600}\x{6900}\x{6100}\x{0f00}\x{bc

Code:
% ~/viv_del1.pl
% ls
Vivian?3

No luck!

Copied your second script to ~/viv_del2.pl after correcting a small typo (~= should be =~):

Code:
% ~/viv_del2.pl
% ls
Vivian?3

Copied your third script to ~/viv_del3.pl:

Code:
% ~/viv_del3.pl
WARN: Unable to rm 2 at /home/sverreh/viv_del3.pl line 6.

Modified the script and saved it in ~/viv_del4.pl:

Code:
% sdiff -sw 155 ~/viv_del3.pl ~/viv_del4.pl
   unlink $i or warn "WARN: Unable to rm $i";  |  unlink [color="red"]$content[$i][/color] or warn "WARN: Unable to rm [color="red"]$content[$i][/color]";

Code:
~/viv_del4.pl
WARN: Unable to rm Vivian?3 at /home/sverreh/viv_del4.pl line 6.

So we are out of luck again!

The idea with the hex editor is interesting, so I tried with hexedit:

First, I changed to the parent directory:

Code:
% cd ..
% ls -l
total 160
drwxr-xr-x  1 sverreh  wheel  32768 May 27 22:22 DCIM
drwxr-xr-x  1 sverreh  wheel  32768 May 27 22:22 MISC
drwxr-xr-x  1 sverreh  wheel  32768 May 28 21:03 PRIVATE
drwxr-xr-x  1 sverreh  wheel  32768 Jun  1 21:55 Pictures
drwxr-xr-x  1 sverreh  wheel  32768 May  4 14:13 Skole

and then

Code:
 % hexedit Pictures
hexedit: Pictures: Not a file.

So your suspicion was right. However I know that vim can read directories, and tried the following:

Code:
% vim Pictures/

which gave me the following display:

Code:
" ============================================================================
" Netrw Directory Listing                                        (netrw v132)
"   /a/pictures
"   Sorted by      name
"   Sort sequence: [\/]$,\.h$,\.c$,\.cpp$,*,\.o$,\.obj$,\.info$,\.swp$,\.bak$,\~$
"   Quick Help: <F1>:help  -:go up dir  D:delete  R:rename  s:sort-by  x:exec
" ============================================================================
../
.swp*

So vim doesn't see Vivian?3 either!
 
Beastie said:
When you said in post #40 that you're still unable to remove the directory, does this include using the MacBook too?

On what OS was the directory first created? MacOS? Because using these characters -- " * / : < > ? \ | -- in a FAT filesystem is forbidden.

No, it does not include the MacBook. There the directory and files seem to be O.K., so I guess deleting it would be no problem. But that would of course take the fun out of this project!

The directory was copied from the Macbook originally.

magickan said:
another way to find the inode is

Code:
find . -ls

Thanks for the idea! I wasn't aware of this possibility in find. But it didn't solve the problem:

Code:
% find . -ls
177152       64 drwxr-xr-x    1 sverreh          wheel               32768 Jun  1 21:55 .
find: ./Vivian?3: Invalid argument

@ pprocacci and @ expl:

I will need some more time to look into your proposals. Be patient!
 
sverreh said:
Sorry for this late answer, but occasionally I am required to do some useful work during the day. Killasmurf, you are incredible! When I read your post suggesting a perl script, I turned around to grab my Camel and Cokbook from the bookshelf. When I turned back, you had already supplied three scripts. (Well, almost :) )
:r

sverreh said:
The idea with the hex editor is interesting, so I tried with hexedit:

First, I changed to the parent directory:

Code:
% cd ..
% ls -l
total 160
drwxr-xr-x  1 sverreh  wheel  32768 May 27 22:22 DCIM
drwxr-xr-x  1 sverreh  wheel  32768 May 27 22:22 MISC
drwxr-xr-x  1 sverreh  wheel  32768 May 28 21:03 PRIVATE
drwxr-xr-x  1 sverreh  wheel  32768 Jun  1 21:55 Pictures
drwxr-xr-x  1 sverreh  wheel  32768 May  4 14:13 Skole

and then

Code:
 % hexedit Pictures
hexedit: Pictures: Not a file.

So your suspicion was right. However I know that vim can read directories, and tried the following:

Code:
% vim Pictures/

which gave me the following display:

Code:
" ============================================================================
" Netrw Directory Listing                                        (netrw v132)
"   /a/pictures
"   Sorted by      name
"   Sort sequence: [\/]$,\.h$,\.c$,\.cpp$,*,\.o$,\.obj$,\.info$,\.swp$,\.bak$,\~$
"   Quick Help: <F1>:help  -:go up dir  D:delete  R:rename  s:sort-by  x:exec
" ============================================================================
../
.swp*

So vim doesn't see Vivian?3 either!

I tried bunch of editors, and those that opened directory refused to save modified data :D [Well I expected that]

Now I have The Most Perverse Idea Ever, I doubt anyone will beat me on this one.
We know file name pattern:D
could open up hex editor, and edit unmounted device directly.
First you need to find file name patern [you don't need to be limited to fine name only, you dumped much more data in previous post], then verify that it is the one. [Shouldn't be too hard, because you can search quite a big pattern] and then modify filename to common sense :D

This is of course brutal force, brutal stupidity, brutal [your word here], and you risk damaging your file system [but this might be fun]

i think editors/hte will suit this purpose best [it installs binary named ht]
 
killasmurf86 said:
Now I have The Most Perverse Idea Ever, I doubt anyone will beat me on this one.
Don't you wish!

killasmurf86 said:
This is of course brutal force, brutal stupidity, brutal [your word here], and you risk damaging your file system
Yeah, all the above... if you don't know what you're doing, muhahaha.

killasmurf86 said:
i think editors/hte will suit this purpose best
My favorite choice too. ;)



kdulep said:
just do newfs already and stop this spam
LOL
 
If a directory is displayed as a file then this would indicate the filesystem is damaged.
You already ran fsck_msdosfs, and MacOS X can read the card properly, so either MacOS is doing something strange, or something is damaged (And MacOS X can read it anyway).

The strange name is a symptom of the same problem, not the cause.
 
expl said:
Compile this cc -o rfiles sourcefile.c
Run ./rfiles /your/path

I compiled it as instructed and did:

Code:
 % ~/rfiles .
 % ls
Vivian?3

I think the problem is that your program deletes normal files, but not directories. And the Vivian?3 is a directory, as shown by the Macbook. To test this, I created two directories and populated them with two files in each:

Code:
% mkdir -p try/try1
% touch try/{f1,f2,try1/{f3,f4}}
% ls try
f1      f2      try1
% ls try/try1
f3      f4

Then I ran rfiles again, and checked the files:
Code:
% ~/rfiles .
% ls
Vivian?3        try
% ls try
f1      f2      try1

So all the files are still there. I then changed to directory try and re-ran rfiles:

Code:
% cd try
% ~/rfiles .
Deleting './f1'. Done!
Deleting './f2'. Done!
% ls
try1
% ls try1
f3      f4

Works perfectly for the normal files, but leaves directory try1 intact. If I were an expert in C (like you seem to be) I could have tried to modify your program to delete directories, but I am not fluent in that language! (very far from, in fact).

Very nice try, thanks a lot for your time and effort!
 
pprocacci said:
You may have luck using fsdb. Be very wary though, this utility has the opportunity of screwing things up royally. Do NOT mount the partition you want to work on....then:

After studying manpages for a long time, I jumped into it:

Code:
# fsdb /dev/da0s1
** /dev/da0s1
Cannot find file system superblock
ioctl (GCINFO): Inappropriate ioctl for device
fsdb: /dev/da0s1: can't read disk label
#

So, no luck!

pprocacci said:
Edit2: I honestly don't think the perl approach will work, but please try and let us know.

As reported in my reply to killasmurf, you are right. Thank you, pprocacci
 
Carpetsmoker said:
If a directory is displayed as a file then this would indicate the filesystem is damaged.
You already ran fsck_msdosfs, and MacOS X can read the card properly, so either MacOS is doing something strange, or something is damaged (And MacOS X can read it anyway).

The strange name is a symptom of the same problem, not the cause.

Could you elaborate a bit on this, Carpetsmoker? The file is displayed with ls, but isn't that normal behaviour even for directories?

Code:
ls -l
does not list the directory as a file, it just reports "invalid argument".
 
sverreh said:
Code:
# fsdb /dev/da0s1
** /dev/da0s1
Cannot find file system superblock
ioctl (GCINFO): Inappropriate ioctl for device
fsdb: /dev/da0s1: can't read disk label
#

So, no luck!
fsdb(8) works on FFS (Fast File System) AKA UFS.

A FAT filesystem has a BIOS Parameter Block, FAT cluster linked lists, and a root directory in the data area (for FAT32). A UFS filesystem has bootblocks, a superblock, and cylinder groups with inode tables and free block bitmaps.
In other words, they are fundamentally different filesystems based on fundamentally different concepts.



sverreh said:
Could you elaborate a bit on this, Carpetsmoker? The file is displayed with ls, but isn't that normal behaviour even for directories?

Code:
ls -l
does not list the directory as a file, it just reports "invalid argument".
The problem is very simple as you found out many posts ago: FreeBSD is confused by the redirection < character. It's 100% MacOS's fault. It should never accept a < character on a FAT filesystem to begin with.
 
Beastie said:
fsdb(8) works on FFS (Fast File System) AKA UFS.

A FAT filesystem has a BIOS Parameter Block, FAT cluster linked lists, and a root directory in the data area (for FAT32). A UFS filesystem has bootblocks, a superblock, and cylinder groups with inode tables and free block bitmaps.
In other words, they are fundamentally different filesystems based on fundamentally different concepts.




The problem is very simple as you found out many posts ago: FreeBSD is confused by the redirection < character. It's 100% MacOS's fault. It should never accept a < character on a FAT filesystem to begin with.

I hadn't realised, when I offered fsdb, that he was working with FAT32, so I apologise for leading astray.


Another option would be to hack up a shell that doesn't use [red]<[/red] as a redirect. I doubt that's a trivial exercise, though. I'm also not sure about the actual commands like ls(1), do they parse redirections that aren't intercepted by the shell?
 
I had a similar problem but the name of the file started with a dash "--filename".

The problem:
[cmd=]# rm "--filename"[/cmd]
Code:
rm: illegal option -- -
usage: rm [-f | -i] [-dIPRrvW] file ...
       unlink file

Then I found this and it worked:
# rm ./--filename
 
This also works:
$ rm -- --filename

The -- will tell rm(1) there are no more options and everything else should be treated as a filename.
 
SirDice said:
This also works:
$ rm -- --filename

The -- will tell rm(1) there are no more options and everything else should be treated as a filename.

To slightly expand on this, using -- is a getopt(3) feature, not a rm-specific feature. From getopt(3):

Code:
     The interpretation of options in the argument list may be cancelled by
     the option ‘--’ (double dash) which causes getopt() to signal the end of
     argument processing and return -1.
 
Yes, basically that means you can use that trick with other commands too.
 
awww

While searching for answers for a slightly different question, I stumbled on this subject. I had wondered about this for yet another problem I have for some other folder and was reading with enthusiasm as each potential solution was proposed and tried. I guess this never concluded, not using FreeBSD anyways.

My trouble is that the file name contains a Korean character copied over from Windows system. My system reads Korean in UTF8 just fine, but can't read that particular character and displays it in ? mark. (e.g. "image재1.jpg" would show up as "image?1.jpg") It wouldn't be deleted or moved or accessed in ordinary ways (haven't tried any of the above-mentioned scripts or other scary looking methods). My guess is that it's encoded in UTF-16 or something. Does anyone have any update to this problem?
 
Back
Top