[
https://issues.apache.org/jira/browse/PDFBOX-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14966770#comment-14966770
]
Adam Hooper commented on PDFBOX-3001:
-------------------------------------
What's their reasoning for writing to /tmp? I understand the homedir approach;
but I can't envision use cases in which writing to a tempdir is better than
just keeping the cache in memory. That goes doubly for applets.
My /tmp uses tmpfs so it costs RAM anyway; and like many /tmp directories, it's
wiped every reboot. Moreover, reading from a predictable tempfile name is one
step closer to a security vulnerability, since anybody can plant a file in /tmp.
Obviously, writing to /tmp would make some invocations faster. But it wouldn't
make them faster in a deterministic manner, and it might create a security
vulnerabilty.
As an end-user, I'd prefer a default `$HOME/.something`, configurable via
system property.
> FileSystemFontProvider cache instability
> ----------------------------------------
>
> Key: PDFBOX-3001
> URL: https://issues.apache.org/jira/browse/PDFBOX-3001
> Project: PDFBox
> Issue Type: Bug
> Affects Versions: 2.0.0
> Reporter: John Hewson
> Assignee: John Hewson
> Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: md5.diff, patch, patch
>
>
> FileSystemFontProvider uses Java's Preferences API to cache font metadata,
> however it doesn't seem to work out of the box on Windows (due to file
> permissions) and one user on the mailing list has complained that on Linux
> file paths with more than 80 characters can't be handed. Serializable is also
> slow.
> It looks like Preferences wasn't a good choice here. We're going to need to
> roll our own cache file format and save it somewhere we have write access to.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
