Home
Posted By: Virtual1 Thunderbird bug confusing time machine? - 06/23/11 03:37 PM
User brought in a computer that time machine keeps erroring out on, with "error: (-41) SrcErr:no" logged in console. (and the usual "it didn't work, maybe try it again?" error message from TM) Googling around shows lots of people with similar errors in time machine but no real help short of deleting the offending file or excluding it from the backup. (not really a good solution)

I get info on the file and am shocked to see 25 permissions for the file, the first 22 of which are (username): Custom. Looking around, many/most/all? of the files in the thunderbird mailstore suffer from this huge permissions list. I'm speculating that TM is having problems because of this. I suppose these are ACLs? Any remedy? got a command I can issue to wipe CUSTOM/ACL accesses in a tree?

It's not necessarily a problem of how many of these perms there are, but one or more of them may be restricting TM from accessing the file, and I don't know how to get more information on these permissions to see what they're trying to do. (fighting each-other would be a good guess?) I'm hoping there's a good CLI command to view/modify/clear ACLs?
Posted By: Virtual1 Re: Thunderbird bug confusing time machine? - 06/23/11 04:35 PM
ok Bresnik has a new version of Tinkertool called "Tinkertool System", and it has a panel to set and propagate ACLs. That appears to have fixed the issue, I just wiped the ACLs from the entire thunderbird profile and the backup appears to be proceeding happily now. Must be a Thunderbird bug? That probably means it'll cause problems again down the road... frown

The first ~20 ACLs were pairs of "custom" and "full access" ACLs, the first of each pair denying the user READ access to the object. Weird. Not sure why the user could read them at all, since technically the first ACL that hits usually applies and stops evaluation, and that would have locked them out of their files. I only tried to copy the files, not open them, maybe you can copy files you can't read? *shrug*


Originally Posted By: Virtual1
got a command I can issue to wipe CUSTOM/ACL accesses in a tree?

chmod -R -N /path/to/folder

[often works just fine without sudo]
Posted By: Virtual1 Re: Thunderbird bug confusing time machine? - 06/29/11 01:32 AM
hmm I thought I'd looked there... -N is not in the man page for chmod!
Posted By: dkmarsh Re: Thunderbird bug confusing time machine? - 06/29/11 02:29 AM

Sure it is, under

ACL MANIPULATION OPTIONS

...

-N Removes the ACL from the named file(s).
In the event that Virtual1's manpage does indeed lack -N, he's probably been bitten by an old (10.5.0 upgrade) bug.

@
Virtual1:
Start here "Re: Moving files to Trash" for background info, and scroll down for ganbustein's one-liner to fix same (in post #443080).


Note: if that page takes forever to load, see this thread in The Lounge for the cure (or, just wait 5 minutes).
Posted By: Virtual1 Re: Thunderbird bug confusing time machine? - 06/29/11 09:11 PM
ahh it's there at the bottom as a detail explanation of the -N option, but it does NOT appear at the top with the brief options list
Posted By: dkmarsh Re: Thunderbird bug confusing time machine? - 06/29/11 10:47 PM

Actually, it appears at the very top:

NAME
chmod
-- change file modes or Access Control Lists

SYNOPSIS
chmod
[-fv] [-R [-H | -L | -P]] mode file ...
chmod [-fv] [-R [-H | -L | -P]] [-a | +a | =a] ACE file ...
chmod [-fhv] [-R [-H | -L | -P]] [-E] file ...
chmod [-fhv] [-R [-H | -L | -P]] [-C] file ...
chmod [-fhv] [-R [-H | -L | -P]] [-
N] file ...


This kind of thing seems to mean "scroll till you find it;" the fact that it's the last option given in the last form of the command listed suggests that you might have to scroll a long way...
Originally Posted By: dkmarsh
scroll till you find it

Both more and less (as used by man) have a bunch of features (and i have trouble remembering more than 2 or 3 myself), but...

h gets us the help screen (and q will quit it)

/ the slash starts a search string, so...
/-n and then return would find the first "-n" (case insensitive)

once a search is under way,
n finds the next, and
N (shift-n) finds the previous

esc-u will get rid of the highlighting, if it becomes too distracting.

[check the help (h), it gets way deeper than that.]

It may well confuse matters here that "n" was both the metacharacter (n for next) and also what we were searching for in this example! grin

--

Hmm, it's an interesting kind of "case-insensitive" search: if we stick with lowercase, it will find any-and-all cases... but if we specify uppercase (using caps), then it becomes case-sensitive on us.

Note: before Tiger (or Panther? perhaps), man used more. Ever since however, it uses less. (just means that the text goes away when we q).
[edit#42a: that may have more to do with the bash version than the OS.]
© FineTunedMac