Re: [Pan-users] [mdk90] 0.13.4 can't cancel own article

[Duncan]

On Wed 19 Mar 2003 12:43, address@hidden posted as excerpted below:
> Greetings  --
>
> I've just applied an upgrade from [mdk90nospell]
> default install - 0.13.0 to [mdk90nospell] 0.13.4 and now when I attempt to
> cancel am receiving an error: Unable to cancel article: couldn't find
> article in folder 'pan.sent'. This was not an issue in the previous
> version. 

> The articles are there; the message IDs are Pan assigned. My directory
> structure is a little different than mentioned in previous posts. Pan has
> created .pan with the .xml, .dat, .idx, etc. in the root .pan folder. There
> are two sub dirs: 'default': containing the subscribed newsgroup .dat/.idx
> files and a 'messages' sub dir: containing two sub dirs called: 'cache' and
> 'folders'. The pan.sent is in the 'folders' sub directory. This directory
> structure is identical to the one created with the 0.13.0 version which
> didn't seem to have a problem finding items in pan.sent To simplify, the
> path to my pan sent is
> .pan/messages/folders/pan.sent
>
> A co-worker running RH8.0 with a slightly different directory structure is
> not having this problem. .pan/data/folders/pan.sent. I'm assuming (for lack
> of better info) that the difference in directory structure is
> distro-specific[?].

I'm on Mdk here, but have everything under .pan/data/ here as well.  Of 
course, sometimes I use the RH RPMs, sometimes Mdk, and sometimes I upgrade 
using the tarballs.  It pretty much depends on what's up by the time I get 
around to upgrading to the next beta after reading the announcement.

Anyway, I don't think it's distrib specific, but rather that the path changed 
somewhere along the line.  Are you trying to cancel messages sent with the 
old version?  That may be the problem.   New messages may go in the new 
location under data.

Have you tried simply moving everything that's now directly under the .pan dir 
to a new data subdir?  I don't know if that will work or not, but given your 
observations, that's what I'd try next.

Also..  there was a known issue at one point with PAN being able to track its 
own user's posts.  It was taking a shortcut, and displaying back the local 
copy rather than d/ling off the server it had just sent the posts to, but 
that turned out to have some seriously undesirable side effects (like not 
having a way of verifying what actually made it to the server).  It is 
possible you are seeing one of them.

-- 
Duncan
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin