Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoid error messages because of hard links #17

Merged
merged 2 commits into from
Nov 9, 2022
Merged

Conversation

stweil
Copy link
Contributor

@stweil stweil commented Nov 9, 2022

Starting of a Docker container can show an error because creating hard links is not possible across filesystems:

ln: failed to create hard link '/models/ocrd-resources/ocrd-tesserocr-recognize/eng.traineddata' => '/usr/local/share/tessdata/eng.traineddata': Invalid cross-device link
ln: failed to create hard link '/models/ocrd-resources/ocrd-tesserocr-recognize/equ.traineddata' => '/usr/local/share/tessdata/equ.traineddata': Invalid cross-device link
ln: failed to create hard link '/models/ocrd-resources/ocrd-tesserocr-recognize/osd.traineddata' => '/usr/local/share/tessdata/osd.traineddata': Invalid cross-device link

In addition, restarting an existing Docker container will always give an error because the hard links already exist.

Using forced symbolic links fixes both kinds of errors.

Signed-off-by: Stefan Weil sw@weilnetz.de

Starting of a Docker container can show an error because
creating hard links is not possible across filesystems:

    ln: failed to create hard link '/models/ocrd-resources/ocrd-tesserocr-recognize/eng.traineddata' => '/usr/local/share/tessdata/eng.traineddata': Invalid cross-device link
    ln: failed to create hard link '/models/ocrd-resources/ocrd-tesserocr-recognize/equ.traineddata' => '/usr/local/share/tessdata/equ.traineddata': Invalid cross-device link
    ln: failed to create hard link '/models/ocrd-resources/ocrd-tesserocr-recognize/osd.traineddata' => '/usr/local/share/tessdata/osd.traineddata': Invalid cross-device link

In addition, restarting an existing Docker container will
always give an error because the hard links already exist.

Using forced symbolic links fixes both kinds of errors.

Signed-off-by: Stefan Weil <sw@weilnetz.de>
Copy link
Member

@bertsky bertsky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, sorry about that – a last-minute change I thought I had tested but did not.

The problem I still have with this setup is that the files on the host side will point to path names inside the container. Since we are talking of just a few megabytes (for the default models we install along with make install-tesseract), I think we should rather cp than ln after all.

start-sshd.sh Outdated Show resolved Hide resolved
Co-authored-by: Robert Sachunsky <38561704+bertsky@users.noreply.github.com>
Copy link
Contributor Author

@stweil stweil left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using cp for such rather small files is a good solution.

@bertsky bertsky merged commit 0e9f8de into slub:master Nov 9, 2022
@stweil stweil deleted the ln branch November 9, 2022 20:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants