No offense taken.
Yes, I would appreciate a more in depth explanation.
Here goes:
Code:
drwx------+ 22 kevinstow-parker staff - 748 Jul 6 10:46 Documents
0: group:everyone deny delete
The initial
d character means it's a directory (folder). A file has a - instead of d. Other things (named pipes, sockets, symlinks) show other characters.
The next 3 chars
rwx are the basic access permissions for the owner. The order is always read, write, exec/search. If a letter is shown, the permission is granted; if a dash (hyphen, minus sign) is shown, the permission is denied. The exec/search permission means "exec" (executable) for files, or "search" for directories.
The next 3 chars
--- are the basic access permissions for the item's group. Again, the order is always read, write, exec/search, and the same "show a letter or dash" applies. Since the value is all dashes, the group has all permissions denied.
The next 3 chars
--- are the basic access permissions for all those other than the owner or a member of the group. Same interpretation: --- is all permissions denied.
There are some other letter possibilities, such as 's' or 't', which don't appear here. Refer to the
man page for the 'ls' command. Since the letters don't appear, it's too long to explain them when they don't apply.
The next char
+ means there is an Access Control List (ACL) for the item. Another possible character here is '@', which means extended attributes. Refer to the ls man page for more details.
An ACL provides a more detailed access control than the 9 basic permissions. This is the ACL entry:
Code:
0: group:everyone deny delete
- 0 means it's the zeroth item in the list.
- group:everyone means the item applies to members of the group named "everyone". (By default, every login user account is a member of this group. It's not a special group, other than being managed by the system. It's just a group named "everyone", that every login account normally belongs to.)
- deny identifies this item as a denial of permission. The opposite would be "allow".
- delete is the name of the specific permission denied. There's about a dozen different possible names. See the man page for chmod.
The
22 is the number of hard-links to this item. For an HFS+ directory, it's approximately equivalent to the number of items in the directory. That's not exactly right, but it's close enough for this case.
The
kevinstow-parker is the user who owns the item. It's the same as the output of the 'id' command, so we know the logged-in user is the owner, so owner permissions (rwx) apply.
The
staff is the group assigned to the item. Since the group permissions are all denied, I have no further description.
The
- shows there are no additional access flags, such as locked. See the
man page for chflags.
The
748 is the length in bytes of the directory's data, i.e. its actual list of files. This number isn't that useful for a directory, at least not for user interpretation.
The
Jul 6 10:46 is the most recent modification date-time stamp. Creating, deleting, or renaming a file within a directory will change this. This is only affected by the immediate items, not changes to the contents of sub-folders or sub-sub-folders.
The
Documents is the item's name.
Summary: the logged-in user is the owner, the owner has rwx permission, and there are no ACLs denying owner permission. All others are denied any access.
Therefore, the user kevinstow-parker should have full access to everything in the directory, including the ability to list, read, create, delete, or rename items in the directory.
In an earlier post I asked BeardRaptus to boot to his SL DVD and do a repair disk, and that did not seem to help or result in any odd output.
Well, you didn't ask him to post any output. One hopes he would have posted it, but you didn't ask and I don't like to assume.
I want to see the complete output before making any corrective suggestions. If there's existing damage, and it's uncorrectable by "Repair Disk", that's a different kettle of fish than if there's no apparent damage at all.
Here's the detailed explanation for:
Code:
ls -RF ~/Documents > ~/Desktop/files.txt
ls: .lo#ali:ed: No such file or directory
The -RF option to the 'ls' command tells it to recursively list everything, which means the entire tree of sub-directories is listed, and to append a '/' to directories, or another special character for other types (symlink, socket, etc.).
The first thing the 'ls' command will do is to get a listing of the named directory
~/Documents. It then sorts this (there's an option that tells it not to sort) and proceeds to recurse into sub-directories.
The initial "get a listing" succeeded, otherwise ls would have complained about that.
Apparently, the first item in the sorted listing of ~/Documents is something with the name
.lo#ali:ed. Although a strange name, it's not completely crazy. In fact, one could create a file using this command:
Code:
touch ~/Documents/".lo#ali:ed"
and it should work.
The concerning part of the output is that there's usually a file in ~/Documents with the name ".localized". I'll show both names:
Notice that some characters are identical but others aren't. This is a classic sign of damaged data.
It may be the data on disk, i.e. the actual item-entry in the directory, is corrupted, or it may be that when it's read in RAM (working memory), the data transfer corrupts it, or it may be that RAM isn't keeping the data correctly.
Whatever the cause, the next thing 'ls' tries to do is get info on the named item. It's the 'stat' system-call, and you can read its man page for details.
When the stat call is made, the OS doesn't find an entry named ".lo#ali:ed", so stat returns an error, and 'ls' stops. Since the name of the item came directly from the listing, stat
should find info, yet it doesn't. This is bad.
So with no other info, I'm pretty sure something is malfunctioning, and doing so in a bad (though possibly intermittent) way.
- It could be bad data stored on the disk. "Verify Disk" may identify this, or it may not.
- It could be that reads from disk experience a corrupted data transfer. Possible causes include an intermittently failing disk, an intermittent disk cable, or possibly a failing logic board.
- It could be that RAM is bad or intermittent.
Running the Apple Hardware Test for the computer may identify disk problems or RAM problems. Or it may not, if the problem is intermittent.
Running "Verify Disk" should identify bad data stored on disk, but it does presuppose that RAM works. If RAM doesn't work reliably, then "Verify Disk" doesn't have reliable data to analyze, so what it shows could be wrong or inconsistent.
Here's a link explaining how to run Apple Hardware Test:
http://support.apple.com/kb/ht1509
It's worth doing regardless of what "Verify Disk" shows.
TLDR:
Run Apple Hardware Test.
See link above.
Post the results.
