Gitlab accepts commits with missing LFS files, which it shouldn't
Basic setup
I have a repository with LFS, and I used it for months without issues (except for some minor lfs client bugs which have been fixed or for which the git-lfs people from github gave me workarounds). The repository is fully public and it is located here on my own gitlab instance powered by the official gitlab omnibus docker container.
What happened:
With a recent commit of mine involving LFS files, a file was committed to LFS except that it's actually missing:
If you clone this repository with LFS installed, it will also lead to a download error:
e@e:~/Develop$ git clone https://gitlab.com/eioaoiaoi
Cloning into 'test'...
remote: Counting objects: 2573, done.
remote: Compressing objects: 100% (192/192), done.
remote: Total 2573 (delta 105), reused 0 (delta 0)
Receiving objects: 100% (2573/2573), 644.90 KiB | 0 bytes/s, done.
Resolving deltas: 100% (1587/1587), done.
Checking connectivity... done.
Downloading docs/font/Quicksand-Light.ttf (20.51 KB)
Downloading docs/font/Quicksand-Regular.ttf (23.27 KB)
Downloading misc/logo/icon.ico (71.62 KB)
Downloading misc/logo/icon.xcf (145.91 KB)
Downloading misc/logo/jellyphoto_orig.jpg (519.08 KB)
Downloading misc/logo/logo.ico (455.33 KB)
Downloading misc/logo/logo.svg.png (61.27 KB)
Downloading misc/logo/logo.xcf (900.90 KB)
Downloading misc/logo/logo_base.xcf (2.26 MB)
Checking out files: 100% (65/65), done.
@:~/Develop$ cd test/
@:~/Develop/test$ git remote update
Fetching origin
@:~/Develop/test$ git fetch origin
@:~/Develop/test$ git checkout testDownloading misc/logo/icon.ico (89.25 KB)
Error downloading object: misc/logo/icon.ico (e5e4a49bcf1adc0c344f8a276dae44a4ad3376b936755c02ba2cc58e3ebab246)
Errors logged to /home/user/Develop/test/.git/lfs/objects/logs/20161115T033306.019425508.log
Use `git lfs logs last` to view the log.
error: external filter git-lfs smudge -- %f failed 2
error: external filter git-lfs smudge -- %f failed
fatal: misc/logo/icon.ico: smudge filter lfs failed
@:~/Develop/test$
The source machine which has this file and from where I pushed this simply does nothing on push and says everything is up-to-date, but the file obviously isn't on the server.
Problem: why is this a reachable system state?
Shouldn't a push be rejected if not all LFS files are added properly? This seems like a state that should never be reached - I would either expect a push to go through without error and all files including all LFS files to be available, or I would expect an error and the entire push to be rejected.
To me it sounds feasible for gitlab to actually verify all pushed LFS file pointers have corresponding files in the LFS server. I really think you should add this and reject pushes if files are missing.