lipdR::readLipd() "Error in unzipper"

[wtraylor]

In R, I am getting an error trying to read a specific LiPD file from the Temp12k collection.

It is this file: https://lipdverse.org/Temp12k/current_version/Duranunlak.EPD.lpd (MD5: 3bb741de65363c5f026d8a8e3ebad39c)

This is the error:

> lipdR::readLipd("Duranunlak.EPD.lpd")
[1] "reading: Duranunlak.EPD.lpd"
[1] "Error: lipd_read: Error in unzipper(path, dir_tmp): No LiPD file at the given path: data/Duranunlak.EPD.lpd\n"
list()

In Python, the file opens without an error message (with lipd.readLipd()), so I conclude that it’s not an error in the file itself, but in the R parser.

Environment

This is the output of sessionInfo():

R version 4.1.2 (2021-11-01)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Arch Linux

Matrix products: default
BLAS:   /usr/lib/libblas.so.3.10.0
LAPACK: /usr/lib/liblapack.so.3.10.0

locale:
 [1] LC_CTYPE=de_DE.UTF-8       LC_NUMERIC=C
 [3] LC_TIME=de_DE.UTF-8        LC_COLLATE=de_DE.UTF-8
 [5] LC_MONETARY=de_DE.UTF-8    LC_MESSAGES=de_DE.UTF-8
 [7] LC_PAPER=de_DE.UTF-8       LC_NAME=C
 [9] LC_ADDRESS=C               LC_TELEPHONE=C
[11] LC_MEASUREMENT=de_DE.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

other attached packages:
[1] lipdR_0.2.3     nvimcom_0.9-124

loaded via a namespace (and not attached):
 [1] magrittr_2.0.2    hms_1.1.1         tidyselect_1.1.2
 [4] R6_2.5.1          rlang_1.0.2       fansi_1.0.2
 [7] stringr_1.4.0     dplyr_1.0.8       tools_4.1.2
[10] packrat_0.7.0     data.table_1.14.2 utf8_1.2.2
[13] cli_3.2.0         ellipsis_0.3.2    arsenal_3.6.3
[16] tibble_3.1.6      lifecycle_1.0.1   crayon_1.5.0
[19] tidyr_1.2.0       tzdb_0.2.0        purrr_0.3.4
[22] readr_2.1.2       vctrs_0.3.8       glue_1.6.2
[25] stringi_1.7.6     compiler_4.1.2    pillar_1.7.0
[28] generics_0.1.2    pkgconfig_2.0.3

[nickmckay]

I suspect this is an issue with the file path "data/Duranunlak.EPD.lpd". After you've downloaded the file, try running it in interactive mode:

L = readLipd()

and then select the file. Let me know if this doesn't work. Also, note that this repository for lipdR is about to be deprecated, and the much newer, and soon-to-be-official version is at github.com/nickmckay/lipdR . However I don't think this is the issue here.

[wtraylor]

Thanks for looking into the issue so promptly.

I had tried the interactive mode. I am sure it has nothing to do with the file path.

[nickmckay]

Hmm,

Well it definitely seems like lipdR is having trouble finding the file. If you enter the full path to the file, like

L = readLipd("/Users/me/Downloads/Duranunlak.EPD.lpd")

Does that help? I tried to replicate this issue, but it's loading properly on my computer. If it's still not working for you I'll see if I can replicate on a Linux machine.

[wtraylor]

You are right! It has indeed something to do with the file path. I was too quick to discount that.

The behavior is rather strange. Here is what works and what doesn’t (assuming you have a copy of the file Duranunlak.EPD.lpd both in the working directory and in a subdirectory data/):

What works

readLipd("Duranunlak.EPD.lpd")
readLipd(normalizePath("data/Duranunlak.EPD.lpd"))
readLipd() # select "s" and type: Duranunlak.EPD.lpd
readLipd() # select "d" and type: .
readLipd() # select "d" and type: data
readLipd() # select "d" and type: data/
readLipd() # select "d" and type: /home/<USER>/data/Duranunlak.EPD.lpd

What doesn’t work

readLipd("data/Duranunlak.EPD.lpd")
readLipd(file.path("data", "Duranunlak.EPD.lpd"))
readLipd() # select "s" and type: data/Duranunlak.EPD.lpd
readLipd("data")

---

There must be something wrong with the interpretation of relative file paths. The file in the subdirectory is found, as it is printed in the error message. Perhaps the issue could have something to do with the trailing \n?

For me that’s good enough to work around the issue. If this repository is going to be superseeded by another package anyway, perhaps the issue can be closed.

[nickmckay]

Thanks for this, it's very helpful. It doesn't surprise me that relative file paths don't work quite right on linux, we haven't tested extensively on the platform. I'll keep this issue open and make a note to remember to look into this in the future.