[
https://issues.apache.org/jira/browse/DERBY-5357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13229140#comment-13229140
]
Knut Anders Hatlen commented on DERBY-5357:
-------------------------------------------
With the patch, dblook doesn't work with databases that have been soft-upgraded
to 10.9 if they contain jar files. dblook.log says:
-- **--> DEBUG: Failed to load jar file
/tmp/jartest/DBJARS/23ce809c-0136-10ee-5e54-0000037b37f8.jar.G1331723919074
java.io.FileNotFoundException:
db/jar/23ce809c-0136-10ee-5e54-0000037b37f8.jar.G1331723919074 (No such file or
directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:120)
at java.io.FileInputStream.<init>(FileInputStream.java:79)
at org.apache.derby.impl.tools.dblook.DB_Jar.doJars(DB_Jar.java:98)
at org.apache.derby.tools.dblook.go(dblook.java:533)
at org.apache.derby.tools.dblook.<init>(dblook.java:142)
at org.apache.derby.tools.dblook.main(dblook.java:97)
at org.apache.derby.iapi.tools.run.main(run.java:57)
> SQLJ.INSTALL_JAR shouldn't use identifier as file name
> ------------------------------------------------------
>
> Key: DERBY-5357
> URL: https://issues.apache.org/jira/browse/DERBY-5357
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.9.0.0
> Reporter: Knut Anders Hatlen
> Assignee: Dag H. Wanvik
> Labels: derby_triage10_9
> Attachments: derby-5357-2.diff, derby-5357-2.stat,
> derby-5357-with-tests-2.diff, derby-5357-with-tests-2.stat,
> derby-5357-with-tests-3.diff, derby-5357-with-tests-3.stat,
> derby-5357-with-tests.diff, derby-5357-with-tests.stat, derby-5357.diff,
> derby-5357.stat
>
>
> When installing a jar file with the SQLJ.INSTALL_JAR procedure, it will copy
> the jar file to a subdirectory of the database directory. The name of the
> stored jar file is based on the qualified name specified by the second
> parameter in the procedure, and becomes something like:
> <DBDIR>/jar/<SCHEMA>/<JAR_NAME>.jar.<VERSION>
> This naming scheme is problematic because the qualified name of the jar file
> is an SQL identifier and may contain any characters, also characters with
> special meaning to the underlying file system.
> One example is this call:
> ij> call sqlj.install_jar('/path/to/toursdb.jar', 'APP."../../../x/jar"', 0);
> 0 rows inserted/updated/deleted
> On Unix-like systems, this will install the jar in a subdirectory of the
> database directory's parent directory, which is clearly unfortunate as the
> database directory should be self-contained (an assumption used when taking
> backup of a database using operating system commands, or when moving the
> database to another location).
> There's probably also a possibility that INSTALL_JAR fails if the identifier
> contains a character that's not allowed in file names on the platform.
> It would be better if the jars were stored in a file whose name is
> independent of the identifier used, so that any valid SQL identifier could be
> used to name a jar file in the database without causing problems.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
