The issue with me is NOT the existence or lack of the specified
attachment path. I used a path that DID exist, and my CFPOP DID save
"all" of the attachments there.
The issue is that CFPOP named every attachment "unknownfile", regardless
of how generateUniqueFilenames was set.
So, at the end of the getAll process, there was only one file in the
attachment path that survived (the one from the latest retrieved message).
Al
On 1/23/2011 3:00 PM, Peter J. Farrell wrote:
Stephen Moretti said the following on 01/23/2011 04:05 PM:
Also, I think you need to make sure that the attachment path exists.
CFPOP won't create it for you.
Just to chime in here. I looked at the source here and I doesn't look
like the directory is made for you if it doesn't exist. I could be
wrong, but I don't see any checking to see if it's a valid directory
(other than a new File(attachementPath) call). I think all we have to
do is:
if !attachmentDir.isDirectory()
attachmentDir.mkDirs();
I checked on ACF8 and it does create the attachmentPath automatically if
the directory does not exist. So this is a compat issue. I'm filing
this as a ticket for future reference:
http://code.google.com/p/openbluedragon/issues/detail?id=304
I hope to have a patch on this soon.
Best,
.Peter
--
Open BlueDragon Public Mailing List
http://www.openbluedragon.org/ http://twitter.com/OpenBlueDragon
official manual: http://www.openbluedragon.org/manual/
Ready2Run CFML http://www.openbluedragon.org/openbdjam/
mailing list - http://groups.google.com/group/openbd?hl=en
