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

[Bluecanary]

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

[Titanium Man]

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!

[mervTormel]

don't try and delete anything any longer!

show us:

% sudo ls -l -R /fullPathTo/trash

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

[eriklager]

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

Erik

[moyashi]

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

[Bluecanary]

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.
sudo ls -la -R /Volumes/OS\ 9\ Disk/.Trashes
Password:
total 0
d-wx-wx-wx 4 peter unknown 92 Feb 25 16:48 .
drwxr-xr-x 64 peter unknown 2132 Feb 28 22:45 ..
drwx------ 2 peter unknown 24 Apr 11 2001 0
drwxrwxrwx 4 peter unknown 92 Mar 1 14:38 501

/Volumes/OS 9 Disk/.Trashes/0:
total 0
drwx------ 2 peter unknown 24 Apr 11 2001 .
d-wx-wx-wx 4 peter unknown 92 Feb 25 16:48 ..

/Volumes/OS 9 Disk/.Trashes/501:
total 16
drwxrwxrwx 4 peter unknown 92 Mar 1 14:38 .
d-wx-wx-wx 4 peter unknown 92 Feb 25 16:48 ..
-rw-rw-rw- 1 peter unknown 6148 Feb 28 22:45 .DS_Store
drwxrwxrwx 4 peter unknown 92 Feb 28 18:05 savedgames

/Volumes/OS 9 Disk/.Trashes/501/savedgames:
total 0
drwxrwxrwx 4 peter unknown 92 Feb 28 18:05 .
drwxrwxrwx 4 peter unknown 92 Feb 28 18:05 .
drwxrwxrwx 4 peter unknown 92 Mar 1 14:38 ..
drwxrwxrwx 4 peter unknown 92 Mar 1 14:38 ..

[mervTormel]

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

rm -i ./.
rm -i ./..

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.

[Bluecanary]

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 ..):
rm: "." and ".." may not be removed
and when I try and delete the directory:
[localhost:OS 9 Disk/.Trashes/501] root# rm -r savedgames
rm: savedgames: Directory not empty

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:

[silicondiode]

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

[Bluecanary]

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

[stetner]

I would try an:ls -li /Volumes/OS 9 Disk/.Trashes/501/savedgames 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

[Bluecanary]

Here's what I get when listing the inodes:
[localhost:.Trashes/501/savedgames] root# ls -lai
total 0
28868 drwxrwxrwx 4 peter unknown 92 Feb 28 18:05 .
28868 drwxrwxrwx 4 peter unknown 92 Feb 28 18:05 .
1385364 drwxrwxrwx 3 peter unknown 58 Mar 1 15:20 ..
1385364 drwxrwxrwx 3 peter unknown 58 Mar 1 15:20 ..
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.

[mervTormel]

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

% df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/disk2s9 7326256 2148640 5177616 30% /
devfs 1 1 0 100% /dev
fdesc 1 1 0 100% /dev
<volfs> 512 512 0 100% /.vol
/dev/disk2s10 7326256 608380 6717876 9% /Volumes/banshee
/dev/disk2s11 7326256 2978620 4347636 41% /Volumes/chunder
/dev/disk2s12 7326256 909136 6417120 13% /Volumes/data
/dev/disk2s13 7326256 2144000 5182256 30% /Volumes/ebola
/dev/disk2s14 7326256 2959176 4367080 41% /Volumes/flivver
/dev/disk2s15 7326256 4388036 2938220 60% /Volumes/gunt
...

% sudo fsck_hfs /dev/disk2s15
** /dev/rdisk2s15
** Checking HFS Plus volume.
** Checking Extents Overflow file.
** Checking Catalog file.
** Checking Catalog hierarchy.
** Checking volume bitmap.
** Checking volume information.
** The volume gunt appears to be OK.

you may have to run that a few times. let us know the results of that.

[Bluecanary]

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.

[stetner]

fsck_hfs on the OS9 disk at /Volumes/OS 9 Disk

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

[stetner]

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

[Bluecanary]

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.

[mervTormel]

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

blue, humor us:

do you have the developers tools installed?

% /Developer/Tools/GetFileInfo ./.
directory: "./."
type: ""
creator: "*"
attributes: avbstclINMed
created: 12/13/2001 04:41:36
modified: 03/01/2002 17:24:24

% /Developer/Tools/GetFileInfo ./..
directory: "./.."
type: ""
creator: "Q?
attributes: avbstclINMed
created: 09/02/2001 20:52:04
modified: 02/17/2002 22:38:20


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.

[Bluecanary]

Here's the GetFileInfo of the both:
[localhost:.Trashes/501/savedgames] root# GetFileInfo ./..
directory: "./.."
type: ""
creator: ""
attributes: aVbstclinmed
created: 02/25/2002 23:48:21
modified: 03/01/2002 22:20:33
[localhost:.Trashes/501/savedgames] root# GetFileInfo ./.
directory: "./."
type: ""
creator: "?attributes: avbstclINMed
created: 01/12/1999 05:12:07
modified: 03/01/2002 01:05:49

And the fsck_hfs:
[localhost:/Users/peter] root# fsck_hfs /dev/disk0s9
** /dev/rdisk0s9
** Checking HFS Plus volume.
** Checking Extents Overflow file.
** Checking Catalog file.
** Checking multi-linked files.
** Checking Catalog hierarchy.
** Checking volume bitmap.
** Checking volume information.
** The volume OS 9 Disk appears to be OK.

[mervTormel]

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.

[Bluecanary]

No matter how hard I try, it won't let me set the file info of ./. ...
[localhost:.Trashes/501/savedgames] root# SetFileInfo -a vINM ./.
[localhost:.Trashes/501/savedgames] root# GetFileInfo ./.
directory: "./."
type: ""
creator: "?attributes: avbstclINMed
created: 01/12/1999 05:12:07
modified: 03/01/2002 01:05:49
[localhost:.Trashes/501/savedgames] root#

As you can see, the folder has been around for over 3 years now, and it originally was part of one of my old games (I believe it was Marathon Infinity, though I have no clue if that's right) I believe. The folder was probably created in OS 8.6, and my drive really wasn't maintained (as far as disk utilites and stuff go) until a month or two ago when I got ahold of a copy of Norton Utilities. It doesn't seem like your everyday error to me, if anyone else has had this problem I'd be mighty suprised.

I think that the next thing I'll try is clearing the inode, unless you can come up with a way to set the info for the file.

[mervTormel]

it looks like you did set the file info. i thought in the first getfileinfo, it said that ./. was V for invisible and all other attribs were off.

now it's visible, inited, no-init rez, and shared. i thought if you could affect that change, you might see different results in dir listings.

same obnoxious double files appear in the listing? still stubborn about getting pinched?

very interesting about that three year old thing. so, here's, possibly, an old OS8 install migrated to OS9, and these files occupied these disk blocks, which was really a folder with some entries in it, which are now very wonky.

one thing i would want to know, as i mentioned earlier, is, are these inodes in use by any other files on the filesystem. been trying to find a way to see that, but the best i could come up with is:

% sudo ls -liaR /Volumes/OS 9 Disk/ | grep "the inode"

where "the inode" is 28868 then again for 1385364

if any other files with those inodes come up for that search other than the trash dot bastards, then, backup/make copies of those files, because they are the same disk blocks. then...

time to cut bait. boot into OS9 and run disk warrior/doctor/wrangler and see what comes up. be careful about fixing anything. it might be best just to see what the disk munchers think about all this first.

if those files are unique inodes, it might be best to dump the trash while in OS9.

[stetner]

The hard pert with this stuff is not knowing enough about how hfs+ works. On a true unix file system a directory is simply a file (in a certain format) that lists names and inode numbers:struct dirent {
u_int32_t d_fileno; /* file number of entry */
u_int16_t d_reclen; /* length of this record */
u_int8_t d_type; /* file type, see below */
u_int8_t d_namlen; /* length of string in d_name */
#ifdef _POSIX_SOURCE
char d_name[255 + 1]; /* name must be no longer than this */
#else
#define MAXNAMLEN 255
char d_name[MAXNAMLEN + 1]; /* name must be no longer than this */
#endif
};
If this was a true unix filesystem, the directory in question would simply have had extra entries for . and .. Given that we know the directory itself is inode 28868, clearing that inode would just remove that directory entry. If it contained any files, the next fsck would find them and note that they did not have a coresponding directory entry and it would link them into the directory 'lost+found' on that partition. You should not really have to clri the 1385364 inode as it refers to .. or the .Trashes/501/ directory which is ok by the looks of things. I am going to do a few tests on a scratch partition to see what happens and I will get back to you.....

[stetner]

Ok, I thought I would mess around with this on a zip disk.
When I tried a clri on an HFS+ partition I got:% sudo clri /dev/disk1s11 319
clri: /dev/disk1s11: superblock magic number 0xffffffff, not 0x11954So it looks like it is no go for HFS+

On a UFS partition: % ll -iR /Volumes/untitled
/Volumes/untitled:
total 4
2 drwxrwxrwx 5 root wheel 1024 Mar 2 17:35 ./
4157 drwxrwxrwt 6 root wheel 160 Mar 2 17:26 ../
992 d-wx-wx-wx 3 root wheel 1024 Mar 2 17:25 .Trashes/
3968 drwx------ 2 stetner wheel 1024 Mar 2 17:35 baddir/
2976 drwx------ 2 stetner wheel 1024 Mar 2 17:30 lost+found/
3 -rw-r--r-- 1 root wheel 0 Mar 2 17:27 sssd

ls: /Volumes/untitled/.Trashes: Permission denied
/Volumes/untitled/baddir:
total 770
3968 drwx------ 2 stetner wheel 1024 Mar 2 17:35 ./
2 drwxrwxrwx 5 root wheel 1024 Mar 2 17:35 ../
4 -rwxrwx--x 1 stetner wheel 779680 Nov 18 17:39 hfspax*

/Volumes/untitled/lost+found:
total 2
2976 drwx------ 2 stetner wheel 1024 Mar 2 17:30 ./
2 drwxrwxrwx 5 root wheel 1024 Mar 2 17:35 ../Note the hfspax file at inode 4 and the baddir at inode 3968.% sudo umount /dev/disk2s2

% sudo clri /dev/disk2s2 3968
clearing 3968
% fsck /dev/disk2s2
** /dev/rdisk2s2
** Last Mounted on /Volumes/untitled
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
UNALLOCATED I=3968 OWNER=root MODE=0
SIZE=0 MTIME=Jan 1 10:00 1970
NAME=/baddir

REMOVE? [yn] y

** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
LINK COUNT DIR I=2 OWNER=root MODE=40777
SIZE=1024 MTIME=Mar 2 17:35 2002 COUNT 5 SHOULD BE 4
ADJUST? [yn] y

UNREF FILE I=4 OWNER=stetner MODE=100771
SIZE=779680 MTIME=Nov 18 17:39 2001
RECONNECT? [yn] y

** Phase 5 - Check Cyl groups
FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? [yn] y

BLK(S) MISSING IN BIT MAPS
SALVAGE? [yn] y

SUMMARY INFORMATION BAD
SALVAGE? [yn] y

7 files, 773 used, 94214 free (14 frags, 23550 blocks, 0.0% fragmentation)

***** FILE SYSTEM WAS MODIFIED *****

% sudo mount /dev/disk2s2 /Volumes/untitled

% ll -iR /Volumes/untitled
/Volumes/untitled:
total 3
2 drwxrwxrwx 4 root wheel 1024 Mar 2 17:35 ./
4157 drwxrwxrwt 6 root wheel 160 Mar 2 17:26 ../
992 d-wx-wx-wx 3 root wheel 1024 Mar 2 17:25 .Trashes/
2976 drwx------ 2 stetner wheel 1024 Mar 2 17:30 lost+found/
3 -rw-r--r-- 1 root wheel 0 Mar 2 17:27 sssd

ls: /Volumes/untitled/.Trashes: Permission denied
/Volumes/untitled/lost+found:
total 770
4 -rwxrwx--x 1 stetner wheel 779680 Nov 18 17:39 #00004*
2976 drwx------ 2 stetner wheel 1024 Mar 2 17:30 ./
2 drwxrwxrwx 4 root wheel 1024 Mar 2 17:35 ../
So the file is still there, but since the directory that contained it is gone (along with the name information) it has been renamed to its inode number. But given that you just wanted to get rid of the directory it would work, to bad only on UFS....

[sao]

I know it's silly, but, have you tried deleting with DropNuke ?

http://www.versiontracker.com/moreinfo.fcgi?id=12664&db=mac

(Please, no stone throwing)

Cheers...

[moyashi]

I just recently got hit by this same problem.

Noticeable symptom is an extremely abnormal counting for the trash dump.
I had 3 folders --- system counted past 40,000 ... I hit cancel to say the least.

Actually at the time I didn't realize I got hit with this.
I cheated and dropped down into 9.1 and just trashed the problem folders.
total time .... 30min+ troubleshooting.
9.1 reboot x2 ... 5 minutes .... ughhhh

questions is how are these ".." files created in the beginning?

I was trashing files owned by other users ... I have a multi-user setup for myself. .... hmmmm

[BeingAndNothingn]

Wow, this thread is old... but I figured I'll post for the benefit of anyone with the same or similar problem(s) that ends up here.

I had a similar issue on my girlfriend's Mac; she had a directory in the trash that showed NO `.' or `..', even with:
sudo ls -halp
It just showed nothing.

I tried booting single-user and using clri, which refused to even try anything because the disk was mounted, and, as it was the root partition, could not be unmounted. Next, I booted her Mac in target disk mode (cmd-T), and mounted it on my Mac. From there, I was able to delete the offending directory with a simple 'rm -rf', no inode voodoo required. (I tried the voodoo first, but clri still doesn't work on HFS+). Interestingly enough, the directory showed 5 files present when I looked at it from my Mac. Strange.

To summarize: you may be able to work-around this type of problem by booting the offending Mac in target-disk mode and fixing the problem from another Mac.

[Hal Itosis]

Yes... very old.

According to man clri:
Clri is obsoleted for normal file system repair work by fsck(8).


Looks like Bluecanary may have run Norton Disk Doctor (post #1),
but perhaps fsck (or using Disk Utility while booted from a system
CD) would have been a better approach.

-HI-