search

kitodo / kitodo-production

Kitodo.Production is a workflow management tool for mass digitization and is part of the Kitodo Digital Library Suite.
http://www.kitodo.org/software/kitodoproduction/
GNU General Public License v3.0
63 stars 63 forks source link

3.0.0-beta4: Bad user home path for script_createDirUserHome.sh #3084

Closed mnscholz closed 4 years ago

mnscholz commented 4 years ago

When clicking "download to home" on a process, the script_createDirUserHome.sh is passed a wrong directory to create. The user home's path is prefixed with the Catalina Home, e.g. /var/lib/tomcat9/file:/usr/local/kitodo/users/...

This stems from method org.kitodo.production.helper.WebDav.downloadToHome(Process process, boolean onlyRead). In the lines URI project = Paths.get(userHome + process.getProject().getTitle()).toUri(); and project = Paths.get(userHome + doneDirectoryName).toUri(); userHome is a URI class which is cast to a string producing something like file:///usr/local/... The triple slash is then collapsed by Paths.get(...) and .toUri() then interprets it as relative file path and prefixes it with the Catalina home / current workdir.

We fixed it by replacing userHome with userHome.getPath(). However, we are not sure, whether this fixes it in all environments.

matthias-ronge commented 4 years ago

I tried to understand that. On Ubuntu 16.04, the user name is correctly transferred to the script and the user directory is successfully created. Under which system environment do you get the error?

mnscholz commented 4 years ago

We are using Ubuntu 18.04, Tomcat 9.0.16, OpenJDK 1.8.0.

Looking again at the code, I don't think this has to do with the OS or Tomcat, but with Kitodo config. When debugging, userHome is always a file: URI. The added prefix is then consistent with the javadoc of URI.toString() and Paths.get(String...), imho. So, I wonder whether userHome can be another type of URI?

We are not using LDAP. Maybe this is the difference?

matthias-ronge commented 4 years ago

In Production 3, we started using URIs for all paths. Technically, this allows us to use other paths outside of file:. This may be necessary when we start using Production with a repository as the file store. However, there is currently no such implementation; at the moment the userHomes are always on the underlying operating system, i.e. within file:.

Maybe you could create a pull request with your suggestion? We can then test whether it works that way.

mnscholz commented 4 years ago

Currently I'm trying to get the 3.0.0 release running. If the problem persists there, I will create a pull request.

Thanks!