Thanks Peter;
Changing the value of the generateUniqueFilenames attribute to a
lowercase "yes" results in slightly better behavior for sure.
The attachments column of the result set is unchanged (a message with
two attachments will simply contain "unknownfile,unknownfile" here), so
that's a bug.
But the attachmentfiles column now has full path entries which end with
names like "45_unknownfile" and "46_unknownfile", and the attachment
directory is filled with these files now - bearing names that are
"unique enough" for my low volume needs. Sure hoping this naming scheme
works with more than 100 attachments...
Thanks again for debugging this for me. I can patiently wait for the
next build now.
Al
On 1/23/2011 5:22 PM, Peter J. Farrell wrote:
Alan Holden said the following on 01/23/2011 06:59 PM:
The issue is that CFPOP named every attachment "unknownfile",
regardless of how generateUniqueFilenames was set.
Ouch, looking at this more closely and I see it is looking for the
string literal of "YES" (case ignored). You're example in your first
email used "true" so it was defaulting to boolean false.
I've entered this as issue:
http://code.google.com/p/openbluedragon/issues/detail?id=306
I'll have a patch on the issue tracker soon, however I don't have
committing rights yet. You can apply my patch to a SVN BER and generate
your own WAR, wait for Andy or Alan to commit the patch or use the
workaround of "yes" for the value for the time being.
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
