Question on cloning a repo about lfs-folderstore HOT 3 CLOSED

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.

from lfs-folderstore.

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.

from lfs-folderstore.

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.

from lfs-folderstore.