walt posted on Mon, 27 Jun 2011 22:40:23 +0000 as excerpted: > On Mon, 27 Jun 2011 22:13:48 +0000, walt wrote: > >> I haven't read enough code to know where the encoding cache is. > > Well, duh. I just spotted the brand-new 'encode-cache' directory in > ~/.pan2, so I don't need to read the code :) > > I just noticed you already said your attachments were plain text. I see > that my text attachments are yyEncoded into a multipart/mixed post. > > So far I don't know why my attachments worked and yours didn't, sorry.
You probably don't have a clue why yet (I'll explain), but you just provided the hint I needed for my answer! =:^) Years ago, someone discovered that the pan of the time was letting attachments set their own file permissions, including executable. A patch soon appeared that stripped the executable bit, but this was after Charles had pretty much disappeared and IIRC before khaley had setup his repo, so released pan continued to sit without this "security enhancement" for some time. Meanwhile, I believe I was the one (but it might have been someone else, I'm too lazy to go back and check, and don't want to wrongly claim credit that might belong to someone else, so do NOT take this as such a claim!) that tested and posted that pan did indeed obey its umask, so if that was set to mask the executable bit, pan didn't save files with that bit set in any case. It's not much of a leap from combining that history with the fact that the executable bit means something vastly different on directories and now this NEW information, that pan just created a fresh cache directory, to guessing what happened, especially since I've ALSO mentioned before that I actually use a small wrapper script to start pan, that takes care of setting up various sundry things before doing so. Connect all those pieces together and what's the very reasonable conclusion? Right. My wrapper script sets pan's umask to strip the executable bit, just in case, and it did just that when it created this new directory. But on directories, the would-be executable bit acts as the enter bit, instead. That is, if it's not set, pan can't actually reach into the directory to work with the files there. That's exactly the symptom I'm seeing! I just checked and indeed, the new dir exists, but doesn't have the executable bit set. I know my problem, now, and how to fix it! =:^) Thanks for the hint! =:^) Pan rarely enough creates directories that I forgot about the umask thing. Plus, until now, I didn't know this feature depended on a newly created directory, so... I expect I'll have no problems once I manually add the execute/enter permission. Thanks again. =^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman _______________________________________________ Pan-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/pan-users
