I'm stuck trying to delete a folder with double "."s
 

I currently have hit a dead end when it comes to emptying the trash. When I try and empty it through the Finder, the file count goes up astronomically high (100,000+), yet there is only one folder in there. When I try to move the folder, the Finder's copy dialog screws over and I have to restart the finder. When I go into the command line and navigate my way to the folder in the trash, I find that it has 2 "." (this directory) files and 2 ".." (above directory) files, and I cannot delete either of them because rm prevents you from doing that. So... I'm stuck :( If anyone here knows what I can try please tell me as I put stuff in my trash a lot (I download a lot of files from the internet and stuff) and having to manually delete the stuff from the command line is becoming a big pain, and I can't stand seeing a "full" trash all the time that I can't empty.

~BC

Hi there, I've played around with my .Trash file some, and it appears that when the GUI trash is emptied, the .Trash file disappears. It reappears or is remade when something is put in to the GUI trash. So, I'd recommend creating a test user, putting something into the test user's GUI trash, then doing the following (as the test user, of course):

cd ~
rm -r .Trash

Now try putting something else in the (test user) GUI trash. If you haven't broken the trash (and I don't think you will have since the .Trash is created again each time you put something into the GUI trash) you are then safe to experiment some MORE until you're satisfied that you can then rm -r the .Trash file in your normal user's home directory. That's just my own humble personal opinion, and it's probably worth what it cost you. :D Good luck!

don't try and delete anything any longer!

show us:
that is, where you "navigate my way to the folder in the trash"

I tried deleting the ~/.Trash folder and it worked fine. It gets re-created when you put something in the trash.
Erik

just wondering can't you just.
the top using quotes and the bottom fighting dot with a dot?

Here's the recursive listing of the .Trashes folder (it's on another volume, so there's only one .Trashes for the whole volume I believe). The stuff in red is the messed up part.

something terribly wrong there.

can you run disk utility verify on it? i would hope that would give you something to repair!

can you navigate to

/Volumes/OS 9 Disk/.Trashes/501/savedgames

and try
er, beware since your empty trash window filled up with 100,000 files, it might be traversing your entire OS9 filesystem. yikes.

whatever game that was, don't play it anymore.

Disk Utility checked out fine. The only other disk utility I have is in Norton Utilities 5, and I have a feeling it won't find the error because it's a UNIX sort of thing and I believe the OS X update for Norton Utilities isn't free for version 5

Here's what I get when I do a rm -i ./. (or any other type of remove on . or ..):
and when I try and delete the directory:
It seems really really weird that the filesystem can handle two sets of two identical files (in name, creation date, permissions, etc) in the same folder, so I guess this may be harder than I think to fix :confused:

. and .. are part of the system
 

sorry if i'm reading your post incorrectly, but if you go anywhere in the file system, every folder has a . and ..

if you type:

cd .

you'll end up in the current directory. if you type:

cd ..

you'll end up in the parent directory. the . and .. are file system components, thus they can't be deleted. DOS has 'em too...

@silicondiode - I'm aware that they're part of the system, but the system expects there only to be one . and one .. in each folder (makes sense, there's only one directory you can be in and there's only one directory it can be in), so when the system sees two of each of those in there it seems to freak out, which is where my problems are being caused. Look at the post earlier where I listed the contents of the .Trashes directory, all the directories have one . and one .. except the savedgames one which has two of each of those.

I would try an:to see if they refer to the same inodes (this is just to satisfy my curiosity).

The reason you are seeing so many files when you try to empty trash is probably that the system is recursing over the extra .. directory.

I would boot up in single user mode and do an fsck_hfs on your / disk.

Doug

Here's what I get when listing the inodes:
Looks like it thinks there's two of the same file for each of those. I'm off to try an fsck_hfs I guess.

yep. what doug said. that's where i was going next.

but, this:

--
I would boot up in single user mode and do an fsck_hfs on your / disk
--

needs to be changed to...

...single user mode and do an fsck_hfs on the OS9 disk at /Volumes/OS 9 Disk

that may be trickier than it sounds. you going to have to know it's /dev/disk name, i think. so before you boot to single user, get it's disk name out of the df command.

but, even better, you can do it while you're up and running, provided you have no files open on OS9...
you may have to run that a few times. let us know the results of that.

I ran it only on that partition (I just used mount in the terminal to figure out what /dev file it was) and it checked out fine, unless my mind is failing me it looks like that may well be what Disk Utility runs to check disks (run Disk Utility and the output looks mighty similar). So, back to the drawing board... maybe I should take a trip to the local Apple Store and see if the geniouses there could help me a bit, I doubt they could, but it's amazing sometimes what Apple teaches those guys.

Right you are, I forgot that he was on his OS9 partition.....

Well, then you could always try to clear the inode(s) and run fsck again. Note that I have not tried this on an hfs+ file system.

CLRI(8) System Manager's Manual CLRI(8)

NAME
clri - clear an inode

SYNOPSIS
clri special_device inode_number ...

DESCRIPTION
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.

SEE ALSO
fsck(8), fsdb(8), icheck(8), ncheck(8)

BUGS
If the file is open, the work of clri will be lost when the inode is
written back to disk from the inode cache.

4th Berkeley Distribution April 19, 1994 4th Berkeley Distribution

I think it's probably worth a try, the partition is an old partition on the drive that used to be in my iMac, I put it in my new g4 temporarily so I could copy files and stuff quickly and easily, so the data on there isn't *extremely* important. I'll go ahead and try it, I'd do anything (besides reformat) to get rid of my trash being full all the time... I keep checking to see what's in my trash and why it has stuff in it, and find that stupid folder haunting me.

doug, what do you make of that?! that makes my nipples ache.

blue, humor us:

do you have the developers tools installed?
yikes! before you clri anything, shunt we see that those inodes aren't pointing to anything good?

blue, can we eyeball your fsck of that volume just for grins?

let's slow down a little.

Here's the GetFileInfo of the both:
And the fsck_hfs:

boy, i'd like to get my hands on that mother-loving bunny-funster. that's one for the record books.

know emacs? emacs has a directory editor mode.

would you try

SetFile -a vINM ./.

and see if any nuts fall off the tree. i think just that ./. file is causing the fits.

BTW, do you happen to know what app created these files entries? or was there an error in moving something in OS9 to the trash? it would be good to know to warn others.