See details here.
For a dataset that is connected with a research paper, preprint, code repository, or other resource, you should get a DOI, and you should get it before the paper is published. The DOI registration creates a permanent record of the dataset and makes it citable.
The procedure to get a DOI is described under Obtaining a DOI. For data supplements to paper publications, the following should be considered specifically:
datacite.yml).
If you do not know the DOI of the paper when you register the DOI for the dataset, enter as much citation information as is available and update the information once the paper is published.For further details see here.
Once a DOI is issued for a dataset, can this dataset be modified, for example, can new data be added?
The original GIN repository that was used to create the registered dataset can be changed after it has been used for a DOI publication. However, changes in the original GIN repository do not automatically introduce changes in the published DOI dataset. If substantial changes have been made to a repository, a new version of the dataset can be published by requesting a new DOI.
At GIN we believe that there should ideally be several ways to achieve the same thing. So to access the data you can:
Of course there is! Here!
Yes, you can! Here is how:
At the moment, it is not possible to share a private repository with someone who does not have a GIN account. There are, however, several options you can use to grant access without requesting that others sign up themselves.
Strictly speaking No. A better answer, however, would probably be: It depends on the size of your data!
Sure! However, if you need guaranteed access to a lot of free storage we expect that you cover the additional costs associated with it. Please get in touch with us about the details. Also, consider that data transfer takes its time. You can of course also set up your own GIN server in-house. We are happy to be of assistance, if necessary.
Uploads through the website should work without issue, but for large, long running uploads there is always a greater risk of the connection timing out or being interrupted and subsequent uploads will need to start over. To reduce the chance of long running uploads through the web form, we recommend submitting large repositories in small chunks and low file numbers to avoid timeouts.
As an alternative to the web upload the GIN command line client GIN-cli will resume a broken upload and makes it easier to keep track of what has been uploaded and what remains to be sent, which is important when uploading multiple files in multiple directories. To this end we recommend using the GIN client for large uploads instead of the web interface.
Deleting branches through the GIN web interface is currently not supported. Deleting a branch is possible using the GIN commandline client to send the git remote branch deletion command. If you are unfamiliar with git or the gin client you can find installation instructions for the client here and a basic usage tutorial here.
To delete the branch, you will need to have the repository cloned to a local directory, then from within the repository run the following command:
gin git push -d origin branchname
where branchname is of course the name of the branch you want to delete.
Sometimes due to a misconfiguration or a network issue, git-annex might fail to contact the GIN server, while git commands still work. This can make the application incorrectly assume that the GIN server does not support git-annex and disable annex support for it. If this is the case, then the configuration file for the repository, which can be found at .git/config inside the local repository directory, will have a line that reads annex-ignore=true.
Git annex support can be re-enabled for the remote by removing the line. Alternatively, the following command, when run from inside the repository, will also toggle the setting to its correct value.
git config remote.origin.annex-ignore false
If your remote is not named origin, make sure to use the correct name in the command.
Under certain circumstances, the GIN CLI can fail to upload (or download) data without giving clear errors about what's going on. A few common scenarios for this happening are described below.
GIN CLI uses git and git-annex to manage repositories. These applications also require a number of common utilities such as SSH and OpenSSL. If old versions of these are already installed on the system, they may behave in different ways than how GIN CLI expects. This is more common on Windows. The GIN CLI Bundle provides all these programs, however other versions of the same programs may exist on the system as well.
If on Windows you used the set-global.bat file to make GIN CLI available everywhere, you can try using the gin-shell.bat instead. If the problem does not occur when running gin upload or gin download --content in gin-shell.bat, then the problem may be fixed permanently by editing the set-global.bat.
Open the file in a text editor and find the following line:
echo %path%|find /I "%curdir%">nul || setx path "%path%;%ginbinpath%;%gitpaths%"
Change it to the following:
echo %path%|find /I "%curdir%">nul || setx path "%ginbinpath%;%gitpaths%;%path%"
Then double click the file to fix the system path. This change will make the GIN CLI version of the programs have higher priority than the other versions.
Some errors don't provide clear error messages through GIN CLI, but can point towards the root of the issue if the underlying git and git-annex commands are used on their own. If you are having trouble uploading or downloading files and the above solution didn't help, the following command might provide more information:
gin annex sync
To upload and download all annexed data as well, run:
gin annex sync --content
Feel free to contact us for further assistance in one of the following ways: Open an issue on the GIN issue tracker, or send an email to gin@g-node.org.
GIN CLI communicates with the GIN server in two ways:
Each method requires separate settings for working with proxies. For git, the proxy must support SSH communication, which isn't always the case with web proxies.
Since GIN CLI runs on the command line, the system proxy settings, which are typically meant for web browsing, don't apply.
Instead, the environment variables HTTP_PROXY and HTTPS_PROXY need to be set.
The method varies based on operating system and command shell:
set HTTP_PROXY=proxy.host:port and set HTTPS_PROXY=proxy.host:port (where proxy.host is the address of your proxy server and port is the port).$Env:HTTP_PROXY = "proxy.host:port" and $Env:HTTPS_PROXY = "proxy.host:port" (where proxy.host is the address of your proxy server and port is the port).export HTTP_PROXY=proxy.host:port and export HTTPS_PROXY=proxy.host:port (where proxy.host is the address of your proxy server and port is the port).export HTTP_PROXY=proxy.host:port and export HTTPS_PROXY=proxy.host:port (where proxy.host is the address of your proxy server and port is the port) should be added to your shell's startup script, e.g., ~/.bashrc for bash, ~/.zshrc for ZSH.For git to use the proxy server through SSH, the SSH configuration settings need to be edited. There is no straightforward, single configuration for setting configuring SSH through a proxy. Please consult with your lab or institution administrator for how to configure SSH to work through the proxy.
I experience slow uploads. Can you help increase the upload speed?
Because we have no control over how the data are routed outside the GIN infrastructure, there is not really anything we can do with respect to upload speed from our end. The service provides upload speeds of up to 100MiB/s depending on the connection.
I am trying to upload files to a GIN repository, but files with a specific file ending e.g. "tif" or "nii" are not uploaded.
GIN is based on git and will respect if files have been excluded from git. Check if there is a .gitignore file at the root of your repository where these files have been excluded.
I committed one file too many. How do I get the file out of the annex before uploading?
An annexed file can be removed from the annex and from gin tracking using the following command.
gin git annex unannex [path/filename]
Note that a commit is required to fully remove a file from gin tracking. Also note that if the file content is not locally available, there will be no message at all and the commit will not change the status.
Make sure to gin get-content [path/filename] first, if the content is only available remotely. You can check which files have no local content by running gin ls.
I removed large files from my project that I did not need any longer. Still my directory requires too much disk space.
When files are deleted from the project, they still remain in the history. If, for example, a file got deleted by mistake in the past, you can go back and restore it.
The deleted file will always remain on the server, but if you want to free up the space locally, there are two ways to achieve this:
gin remove-content [large_file] command. Now you can safely delete the file without any leftover space occupied in your local history. You can still checkout an earlier commit and retrieve this file from the server.I dropped the file content of one file and suddenly the content of multiple files got removed!
git annex references files only once. If multiple, identical copies of a file exist at several places within the same repository, dropping the file content of one of these files will lead to dropped file content for all of these files.
A gin upload of files has failed with an unspecified message, e.g.
gin upload data_directory/*
:: Adding file changes
"data_directory/file_one.tif" failed
"data_directory/two.tif" failed
Run gin sync and check if this resolves the current upload issue.
This will download changes from the remote repositories and then
upload any local changes to the remotes.
If it does not help, run gin --version and check the current
GIN client version number. If it is below 1.12, it might
be helpful to upgrade to the latest version of the client and
run the upload again. You can also try to update the git binary on
the local machine.
Further check the client logfile; it can be found at the following locations depending on the operating system:
C:\Users\<User>\AppData\Local\g-node\gin\gin.log/Users/<User>/Library/Caches/g-node/gin/gin.log/home/<User>/.cache/g-node/gin/gin.logBefore checking the log, try to run the upload command again to make sure that the failure and any pertinent information is included as the last entry in the logfile.
On uploading to GIN, we encounter the following error, what is the issue and how can it be resolved?
:: Uploading
Compressing OK
Connection to gin.g-node.org closed by remote host.
fatal: the remote end hung up unexpectedly
fatal: sha1 file '<stdout>' write error: Broken pipe
fatal: the remote end hung up unexpectedly
Pushing to origin failed.
git-annex: sync: 1 failed
[error] 1 operation failed
This error can occur when too many small files (each size < 10MB) with a total size of >4GiB have been committed with a single commit. Try splitting such a commit into multiple smaller ones so that the total sum size of committed files is below 4 GiB.
The reason behind this issue is that by default only files with size > 10MB are checked into git annex. Files with a smaller size are still checked into git, which does not handle many or large files nearly as well as git annex does. In the described case, git cannot handle the sum size of files any longer and will fail on upload.
When trying to upload data to the GIN server, the GIN client prompts "[error] 1 operation failed". What went wrong and how do we fix it?
This error can occur under certain unusual circumstances. One is when trying to upload many small files (individual size < 10MB) with a total size of >4GiB that have been added in one single commit, which is something git does not handle well (see above). If this is the case, please try splitting the commit into a couple of commits with fewer files in each commit and try uploading again.
If this is not the case, please check the client logfile; the logfile contains more detailed information. Depending on the operating system the logfile can be found at:
c:\users\{user}\appdata\local\g-node\gin\gin.log/home/{user}/.cache/g-node/gin/Users/<User>/Library/Caches/g-node/gin/gin.logIf the log shows an error after git annex metadata --json --key=MD5-<hash> you can try to manually upload again using the command gin annex copy --to=origin <filename> with the file that caused the issue.
I cannot clone a repository or upload from my machine to the GIN repository. I constantly get lots of error lines ending in:
# Example repository clone
gin get myusername/tmp
Downloading repository Repository download failed. Internal git command returned: Cloning into 'tmp'...
remote: Enumerating objects: 516, done.
remote: Counting objects: 100% (516/516), done.
remote: Compressing objects: 100% (224/224), done.
client_loop: send disconnect: Broken pipeiB | 1006.00 KiB/s
fetch-pack: unexpected disconnect while reading sideband packet
fatal: early EOF
fatal: index-pack failed
[error] 1 operation failed
# Example repository upload
[stderr]
fatal: There is no merge to abort (MERGE_HEAD missing).
2022/04/21 20:16:13 The following error occured:
Connection to gin.g-node.org closed by remote host.
send-pack: unexpected disconnect while reading sideband packet
fatal: sha1 file '<stdout>' write error: Broken pipe
fatal: the remote end hung up unexpectedly
Connection to gin.g-node.org closed by remote host.send-pack: unexpected disconnect while reading sideband packetfatal: sha1 file '<stdout>' write error: Broken pipefatal: the remote end hung up unexpectedly Pushing to origin failed.
git-annex: sync: 1 failed
2022/04/21 20:16:13 Exiting with ERROR message: 1 operation failed
This error can occur when the connection cannot handle a large upload. There is no easy option to deal with this issue from the machine the error occurs on.
At the core of this issue lies a problem that git cannot prepare and provide data that is supposed to be uploaded in a reasonable timeframe; the server ready to receive the content has to wait too long and closes the connection.
Check the following threads from users experiencing this or a similar issue on a multitude of git services and potential solutions
You can ask questions, report problems or ask for general help by opening an issue here.
GIN is using git-annex to manage large files. Read more here. The fact that the content of these files is not shown, but instead a link to the location where it is supposed to be is shown, might mean either that
این کار باعث حذف صفحه ی "FAQ Troubleshooting" می شود. لطفا مطمئن باشید.