It seems that several deposits from HAL now are ingested with the root directory having a 000 mode, see:
We need to understand where this comes from: the original tarballs, or a glitch in the loader?
It seems that several deposits from HAL now are ingested with the root directory having a 000 mode, see:
We need to understand where this comes from: the original tarballs, or a glitch in the loader?
Here is more material to help: the image of what is shown in the webapp, with mode d--------
and what one gets with the download, that is not d--------
$ tar tzvf ~/Downloads/2028b86e77e21a66f522a8d0e2bcf6c341f6a4b4.tar.gz
drwx------ swhworker/swhworker 0 2020-10-09 09:24 2028b86e77e21a66f522a8d0e2bcf6c341f6a4b4/
drwxr-xr-x swhworker/swhworker 0 2020-10-09 09:24 2028b86e77e21a66f522a8d0e2bcf6c341f6a4b4/abelianbnf/
-rw-r--r-- swhworker/swhworker 64 2020-10-09 09:24 2028b86e77e21a66f522a8d0e2bcf6c341f6a4b4/abelianbnf/AUTHORS
-rw-r--r-- swhworker/swhworker 35149 2020-10-09 09:24 2028b86e77e21a66f522a8d0e2bcf6c341f6a4b4/abelianbnf/COPYING
-rw-r--r-- swhworker/swhworker 175 2020-10-09 09:24 2028b86e77e21a66f522a8d0e2bcf6c341f6a4b4/abelianbnf/LICENSE
-rw-r--r-- swhworker/swhworker 2371 2020-10-09 09:24 2028b86e77e21a66f522a8d0e2bcf6c341f6a4b4/abelianbnf/README
-rw-r--r-- swhworker/swhworker 34016 2020-10-09 09:24 2028b86e77e21a66f522a8d0e2bcf6c341f6a4b4/abelianbnf/abelianbnf.gp
-rw-r--r-- swhworker/swhworker 3735 2020-10-09 09:24 2028b86e77e21a66f522a8d0e2bcf6c341f6a4b4/abelianbnf/certifyfast.gp
-rw-r--r-- swhworker/swhworker 1621 2020-10-09 09:24 2028b86e77e21a66f522a8d0e2bcf6c341f6a4b4/abelianbnf/certifyslow.gp
-rw-r--r-- swhworker/swhworker 1809 2020-10-09 09:24 2028b86e77e21a66f522a8d0e2bcf6c341f6a4b4/abelianbnf/examples.gp
-rw-r--r-- swhworker/swhworker 4444 2020-10-09 09:24 2028b86e77e21a66f522a8d0e2bcf6c341f6a4b4/abelianbnf/test.gp
-rw-r--r-- swhworker/swhworker 2404 2020-10-09 09:24 2028b86e77e21a66f522a8d0e2bcf6c341f6a4b4/abelianbnf/unconditional-cyclotomics.gp
In our data model, Directories never have any permission bits set. That's what's being (confusingly, I guess?) reported by the webapp. That's not specific to deposits at all.
I can't seem to navigate the __MACOSX directory of the first directory, which smells like a bug of the webapp; but navigating the other directories works just fine.
Ok thanks, so it seems more an issue about presentation.
I can't seem to navigate the __MACOSX directory of the first directory, which smells like a bug of the webapp; but navigating the other directories works just fine.
Indeed, I had issues navigating that directory too...
Ack, I will remove the display of permission bits for the directories then.
I will also look at the navigation bug.