Question on cloning a repo
diemora opened this issue · 3 comments
Hi, I don't know if this is an issue or a configuration problem on my side. I follow the steps in the section "Cloning a repo" but when I run the command "git reset --hard master" got this error:
Error downloading object: C0139.MP4 (ee6d455): Smudge error: Error downloading C0139.MP4 (ee6d4556b6bfff6d338ce58f4f52ed349127bcf1b1e0772ccc0061fe957d3881): Error transferring "ee6d4556b6bfff6d338ce58f4f52ed349127bcf1b1e0772ccc0061fe957d3881": [3] Cannot stat "/Users/diego/Desktop/git_bkp/git_storage/lfs/ee/6d/ee6d4556b6bfff6d338ce58f4f52ed349127bcf1b1e0772ccc0061fe957d3881": stat /Users/diego/Desktop/git_bkp/git_storage/lfs/ee/6d/ee6d4556b6bfff6d338ce58f4f52ed349127bcf1b1e0772ccc0061fe957d3881: no such file or directory
Looking into the LFS storage folder I found the name of the file is "4556b6bfff6d338ce58f4f52ed349127bcf1b1e0772ccc0061fe957d3881" and no "ee6d4556b6bfff6d338ce58f4f52ed349127bcf1b1e0772ccc0061fe957d3881, so if I change the name of the file in the storage and add "ee6d" at the beginning, it works.
Thanks!
I'm running into a similar error message. In my case I've wiped the repo and cloned it from a remote on an NAS. Config file looks the same as the machine that's doing the upload, and it's working fine. I'm not sure what the issue here is.
In my case it looks like it's not creating any of the subdirectories it needs.
For what its worth I just got this working - it was a config problem on my end. I had specified the folder arg to be the local working directory. When I changed it to the target directory on the NAS, everything worked great.
I think I might have figured out what the OP's problem was (a little late, sorry) - it's only because I only recently discovered that both GitLab and Gitea store their LFS files in a slightly different path to the way local Git LFS does.
When I made this plugin I decided to keep things simple, identical to the way LFS stores things locally, so an LFS files with hash ee6d4556b6bfff6d338ce58f4f52ed349127bcf1b1e0772ccc0061fe957d3881 is stored as ee/6d/ee6d4556b6bfff6d338ce58f4f52ed349127bcf1b1e0772ccc0061fe957d3881 (note how the file name is the entire hash).
GitLab and Gitea store the same file as ee/6d/4556b6bfff6d338ce58f4f52ed349127bcf1b1e0772ccc0061fe957d3881 - i.e. the hash is split between the folders and filename. It doesn't matter so long as you're only accessing these LFS files through GitLab/Gitea, but if you try to repurpose this storage directly for use with lfs-folderstore, it won't work because the filenames don't match the expected pattern. You'd have to rename every file to prefix it with the 2 parent folder names in order to use it directly. So I suspect that at some point the OP migrated some LFS data directly from a GitLab or similar storage onto a NAS and tried to use it with lfs-folderstore - that can work but you'd have to rename all the files.