[Big Mac]

Can someone tell me what was going on here? I've listed some questions at the end of my tale.

Symptom: I noticed recently that I could not open my system's Shared folder through the Finder, regardless of the account (admin or non-admin) tried. The Finder would attempt to open it and then beach ball.

Troubleshooting: I thankfully found I could view the whole folder in Terminal, but I didn't know which file was causing the issue. I assumed it was one recently added, but another problem presented itself: how to get ls to show me the files by modification date. I'm not a Unix guru, so a trip to man told me the t flag would sort by time modified. Pretty quickly I narrowed the possible list of offenders to one. This was a file I myself had moved to the Shared folder. . .

I next attempted to cp it to another folder to confirm it was indeed at fault, but the copy failed. Okay, I thought, I'll just rm it - no dice. Instead, I got the response "override rwx---- <user>/<user> for file.txt?" I thought the proper response in turn was y, but it told me permission was denied. Not flustered quite yet, I sudoed and tried the same command. . . and got the same result! I was now beginning to worry there was some significant problem with my drive's directory or something similar. But before panicking, i decided to go to the apparent "owner" and see if that account could view or delete the file. First I (needlessly) logged that user out, thinking perhaps the file was open there and resisting my attempts to kill it for that reason. Nada. My next step was to attempt to open Shared again in that user. Much like my admin user, viewing Shared crashed the Finder, although in that account the Finder got as far as drawing the blank window before dying. Then I moved to the terminal in said account. I was rather sure that this attempt would fail just like before, but instead a regular old rm did the trick.

Questions:
1. Is it safe to say the Finder screwed up and failed to properly chmod the file?
2. Why couldn't the owner user see it in the Finder either?
3. Why wouldn't sudo let me complete the rm?
4. Could I have possibly chmoded it manually (in order to remedy the Finder's error)?
5. If not, how could I have possibly dealt with the file if the user that created it was no longer around?

[badidea]

I have no idea but I would be very interested in answers to those questions, too!!
(I also have weird permission problems that I didn't manage to fix so far - DiskUtility claims to fix them...but it doesn't)

[proton]

If you try and remove a file from the command line that is Locked in the Finder you will receive the message:
override rw-r--r-- user/group uchg for testfile?
Even if you say yes to this you will then receive:
rm: testfile: Operation not permitted

You should either remove the Locked flag in the Finder Get Info window, or you can remove it on the command line using chflags nouchg testfile.

You should be able to remove the file then. This is not an error, this is how permissions are designed to operate. Additionally, for files that aren't part of the system (any files in your user folder fit under this description), repair permissions can not fix any odd permissions because it simply does not check them. Repair permissions fixes only a certain very specific set of permissions which are actually relatively rarely actually the problem.

- proton

[Big Mac]

Thank you for the information, proton. I had no idea the Finder's lock could override sudo.

[alphasubzero949]

Do you ever recall locking this file? Or was this file created through an app? Some apps *cough*Norton*cough* have been known to go around locking files for no apparent reason.

[Big Mac]

Nope, I don't recall locking it, and I don't use any Norton products.

[Big Mac]

Well, it seems that I have a number of these screwed up folders on my drive, all from the same source: my OS 8 Mac. I am now going over each file with chflags. proton, could you explain why the Finder chokes in these circumstances when the flag is set? Surely Mac OS lock flags can't cause the Finder to choke all the time, right?

edit: This particular case differed a bit from the previous one. By process of elimination I've finally found the group of three responsible for this very similar Finder crash. And now, looking in the sub-directories of the folder I finally have access to, I see there's another problematic file.

[proton]

The Finder should not choke simply looking at locked folders, but it won't be able to delete them without you removing the flag. There may be bugs which cause it to choke however, but I haven't been able to trigger any.

You should be able to see files/folders that are locked by the lock badge icon in Mac OS X. Without really looking into the exact circumstances of the folder it's pretty hard to tell why the Finder may be choking on it.

- proton

[Big Mac]

The folders/files that cause it to die all came from my 8600/300, including the file that caused this thread to be created. When I copied the data over from my 8600, I had to use my iBook connected through Ethernet and my 2G iPod connected to my iBook as the destination drive. Not only did the data have to travel a long path, it had to go over an older, abused ethernet cable to my iPod that had also taken some rough hits. It's thus little surprise that a number of things got damaged along that twisted route. Furthermore, it's actually quite surprising that so little of the transfer actually got corrupted; most of the damaged files are not that important. Whatever the copying error that occurred then was, the attempt to draw a given folder is killing the Finder until I'm able to locate and rm those files that have been damaged. Once I get rid of said files, the folder loads correctly and the other files within appear to be fine. I suppose it's actually a good thing that the Finder is reacting in this way, or else I would never recognize the problem with those files. Thank you again for the assistance, proton.

[proton]

That's really still fairly odd. If the files were written by a functioning OS X machine they should be fine. The worst that could have happened is that the file data got corrupted, there shouldn't be any problems with disk directory integrity etc.

If OS X is attempting to generate a preview of some of the files (column view would do this at least) it may cause the Finder to have problems, but in Tiger this should happen on a background thread and not cause the Finder to choke.

At least you've got a solution that works

- proton

[Big Mac]

This problem just got a little more intriguing. I took an older backup CD of the same folders and tried to view it on my G5; the exact same Finder crash occurs. I then put the same CD in my iBook 466 and attempted to view the same folders, but there the issue did not occur. So, it wasn't corruption of the copy to my iPod, nor was it corruption of my G5's copy. Both my iBook and G5 are running 10.3.9. Just what strange thing is going on here? This issue is pushing me toward installing Tiger, despite my misgivings. My G5 is almost out of its one year warranty, so I'd like to ensure it's healthy while I'm still covered.

Additional note: This issue also crashes PathFinder in the same way, so I guess it's some type of lower level filesystem call failing. And yet, the Terminal functions normally, and the Finder is even capable of copying the problematic folders; it remains the case that the only folders seemingly affected are the ones from my 8600/300.

[Tyre MacAdmin]

Have you checked the filesystem for corruption? Just a possibility.

[Big Mac]

I thought about that, Tyler, but it's also happening on my CD backup of the same folders.

[CharlesS]

I was going to say bad sectors, but the fact that it's happening on other disks as well makes me confused.

That's a weird enough problem that I'd probably archive and install the OS. If you haven't upgraded to Tiger, this does make a nice excuse to do so...

[McMark]

Just reading this thread and noticed something you said proton , namely ('if OS X is attempting to generate a preview of some of the files (column view would do this at least) it may cause the Finder to have problems, but in Tiger this should happen on a background thread and not cause the Finder to choke.")
This appears to be my problem. The sbbod occurs for at least a minute every time a select preview mode on a video file.
Is there a fix for this.
the finder is driving me mad cos it locks up the desktop.
Cheers
McMark

[Big Mac]

I did finally do an Archive and Install upgrade to Tiger, as CharlesS suggested, and it cured the problem.