[
https://issues.apache.org/jira/browse/DERBY-5357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13221048#comment-13221048
]
Dag H. Wanvik commented on DERBY-5357:
--------------------------------------
ij> select * from sys.sysfiles;
FILEID |SCHEMAID
|FILENAME
|GENERATIONID
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
08264012-0135-d0d5-9c5b-0000070b2ff0|80000000-00d2-b38f-4cda-000a0a412c00|../../../x/jar
I think my code doesn't modify the FILENAME in SYSFILE, cf the select above.
Here is the contents of the jar dir in wombat:
/export/home/dag/wombat/jar/APP:
total used in directory 390 available 10570418
:
-rw-r--r-- 1 dag staff 273331 2012-03-02 01:40
.._.._.._x_jar.jar.G1330648558257
This mapping would would for all the three sqlj.* stored procs I believe. I'll
look some more at your case 4).
A problem with my approach is, as you say, that if (and only if) '/' or '\'
were used in in a SQL id for a jar an old release, it would fail on upgrade:
the jar would not be found.
Another problem is that the mapping in the patch is effectively a hash: there
maybe be a chance of collision, e.g. identifiers "a_b" and "a/b" would both map
to filename "a_b".
> 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.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
