Like MadeInGermany, I'm not a MAC user either so I'm now going to talk generic Unix/Linux only. You will need a MAC expert to guide you if you want to use anything I'm going to say now.
Many Unix/Linux OS's implement an often undocumented command called clri which will destroy an inode (by writing zeros to it). A nuclear option. A quick search on Google tells me that MacOS implements this command too. I also see that it implements fsck_hfs.
Therefore my final nuclear option on an OS I'm expert on would be:
1. Ensure that you have just completed a backup of the filesystem (and perhaps preferably the whole system) and know how to restore if it goes wrong. Keep users off afterwards.
2. ls -li has given you the inode number of zombie so run clri to nuke it. BE CAREFUL to specify the correct filesystem on the command line if you have more than one filesystem otherwise you could zap the wrong inode. I cannot give you the MacOS syntax. Try man clri to see if it's offically documented.
3. Once the inode is nuked go into single user mode and run fsck_hfs. The allocated blocks for zombie should show as "missing blocks" and the utility should ask your okay to fix the superblock.
Now I repeat, this is a generic suggestion and you should await input from a MacOS expert on here as to whether they think this method is a goer. I take no responsibility whatsoever but it is how I would fix such a problem on some Unix/Linux filesystems.
This will be my last post to this thread because I'm out of my comfort zone.
This is also my last attempt.
YOU USE THIS AT YOUR OWN RISK!
I discovered that Windows CP 1252 certainly does have these characters as single bytes in it.
REMEMBER! You are messing with a file that is NOT native to OSX 10.11.x.
Save/backup everything you need before removing the final '#' on the last line and then executing this code. WWW.UNIX.COM and its helpers in this thread do NOT hold any responsibility for anything that goes awry.
IMHO a glob match returns even unprintable characters.
So the last proposal does not improve anything.
And the clri command (didn't know it yet), will cause extra harm.
It is useless to clear the inode of the file, because an inode contains the data block structure and all meta information BUT THE FILENAME.
The filename and the pointer to the inode is stored in the directory.
The directory is another inode. To have an effect you must clear the directory inode.
I expect less damage with
if supported by the OS. If successful, you need a full file system check, in order to collect the dangling file inode and its data blocks.
I successfully did that a couple of times on a non-journaling UFS in single-user mode (no desktop, no other processes running).
I would go for a disk editor. Find the offending name, compare the shown bytes with the characters from the ls command, change one byte, save, compare again, ...
@MadeInGermany............Your synopsis of the filesystem structure is, of course, absolutely correct. The filename is in the directory inode but in my experience, if you nuke the file inode when fsck comes along it will see that the directory entry points to a now non-existant inode and ask approval to remove the file. But yes, if fsck falls over at that point because the filename is illegal or doesn't clear the file entry, then you are right that the directory inode would need to be identified and zapped in the same way too (which is possible because the file in question is the only entry in the directory). fsck can then be run again to clear up the mess. I've done this many many times when working on filesystem internals, the problem these days is that many OS's do not provide or implement clri.
I take your point that unlink directory is an easier approach if it works so let the OP try that first.
NOTE: In this case for fsck read the MacOS fsck_hfs.
Clri is obsoleted for normal file system repair work by fsck(8).
Clri zeros out the inodes with the specified inode number(s) on the filesystem residing on the given special_device. The fsck(8) utility is
usually run after clri to reclaim the zero'ed inode(s) and the blocks previously claimed by those inode(s). Both read and write permission
are required on the specified special_device.
The primary purpose of this routine is to remove a file which for some reason is not being properly handled by fsck(8). Once removed, it is
anticipated that fsck(8) will be able to clean up the resulting mess.
Shell script logic
I have 2 input files like with file 1 content as (file1)
"BRGTEST-242" a.txt "BRGTEST-240" a.txt "BRGTEST-219" e.txt
File 2 contents as fle(2)
"BRGTEST-244" a.txt "BRGTEST-244" b.txt "BRGTEST-231" c.txt "BRGTEST-231" d.txt "BRGTEST-221" e.txt
I want to get... (22 Replies)
I need to compare 2 text files with around 60000 rows and 1 column. I need to compare these and write the mismatch data to 3rd file.
File1 - file2 = file3
wc -l file1.txt
wc -l file2.txt
head -5 file1.txt
101214100500... (10 Replies)
I'm a great fan of this forum... it has helped me tone my skills in shell scripting. I have a challenge here, which I'm sure you guys would help me in achieving...
File A has a list of job ids and I need to compare this with the File B (*.log) and File C (extend *.log) and copy... (6 Replies)
I've some files created by a script.
For some reason last time the script run was interrupted for an error and the files produced by the script are undeletable.
i've tryed as root with command 'rm' and even if i got no error in command execution the files are still there.
These are the... (9 Replies)
when i try to ls -lrt the directory, the "undeletable" file is listed.
but when i try to ls -lrt *exe, the "undeletable" file is not listed.
this "undeletable" is the file that i want to delete from the directory.
but when i try to delete/rename/copy.... it, it show that "No such file or... (10 Replies)