Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LFS locks "locked_at": inconsistent precision + LFS spec violation #7871

Closed
slonopotamus opened this issue Aug 14, 2019 · 1 comment · Fixed by #7872
Closed

LFS locks "locked_at": inconsistent precision + LFS spec violation #7871

slonopotamus opened this issue Aug 14, 2019 · 1 comment · Fixed by #7872
Labels
Milestone

Comments

@slonopotamus
Copy link
Contributor

slonopotamus commented Aug 14, 2019

  • Gitea version (or commit ref): 1.10.0+dev-156-g8101d803e
  • Git version: 2.22.0, though doesn't matter
  • Operating system: Linux, though doesn't matter
  • Can you reproduce the bug at https://try.gitea.io:
    No (try.gitea.io is down), but I can reproduce it on https://gitea.com
  • Log gist:
$ git clone git@gitea.com:slonopotamus/gitea-blog.git
Cloning into 'gitea-blog'...
remote: Enumerating objects: 777, done.
remote: Counting objects: 100% (777/777), done.
remote: Compressing objects: 100% (343/343), done.
remote: Total 777 (delta 318), reused 726 (delta 299)
Receiving objects: 100% (777/777), 4.26 MiB | 1.46 MiB/s, done.
Resolving deltas: 100% (318/318), done.

$ cd gitea-blog

$ GIT_TRACE=1 git lfs lock Makefile 
23:49:19.390102 git.c:704               trace: exec: git-lfs lock Makefile
23:49:19.390122 run-command.c:663       trace: run_command: git-lfs lock Makefile
23:49:19.392307 trace git-lfs: exec: git 'version'
23:49:19.393810 trace git-lfs: exec: git '-c' 'filter.lfs.smudge=' '-c' 'filter.lfs.clean=' '-c' 'filter.lfs.process=' '-c' 'filter.lfs.required=false' 'rev-parse' 'HEAD' '--symbolic-full-name' 'HEAD'
23:49:19.395162 trace git-lfs: exec: git 'config' '-l'
23:49:19.395913 trace git-lfs: run_command: ssh -- git@gitea.com git-lfs-authenticate slonopotamus/gitea-blog.git upload
23:49:20.215639 trace git-lfs: HTTP: POST https://gitea.com/slonopotamus/gitea-blog.git/info/lfs/locks
23:49:21.521682 trace git-lfs: HTTP: 201
23:49:21.521743 trace git-lfs: HTTP: {"lock":{"id":"2","path":"Makefile","locked_at":"2019-08-14T20:49:21.392551447Z","owner":{"name":"slonopotamus"}}}
Locked Makefile
23:49:21.523013 trace git-lfs: filepathfilter: rewrite ".git" as "**/.git/**"
23:49:21.523026 trace git-lfs: filepathfilter: rewrite "**/.git" as "**/.git"
23:49:21.523060 trace git-lfs: filepathfilter: accepting "tmp"

$ GIT_TRACE=1 git lfs locks
23:49:24.582212 git.c:704               trace: exec: git-lfs locks
23:49:24.582235 run-command.c:663       trace: run_command: git-lfs locks
23:49:24.584455 trace git-lfs: exec: git 'version'
23:49:24.585256 trace git-lfs: exec: git '-c' 'filter.lfs.smudge=' '-c' 'filter.lfs.clean=' '-c' 'filter.lfs.process=' '-c' 'filter.lfs.required=false' 'rev-parse' 'HEAD' '--symbolic-full-name' 'HEAD'
23:49:24.586718 trace git-lfs: exec: git 'config' '-l'
23:49:24.587855 trace git-lfs: run_command: ssh -- git@gitea.com git-lfs-authenticate slonopotamus/gitea-blog.git upload
23:49:25.396155 trace git-lfs: HTTP: GET https://gitea.com/slonopotamus/gitea-blog.git/info/lfs/locks
23:49:26.614518 trace git-lfs: HTTP: 200
23:49:26.614583 trace git-lfs: HTTP: {"locks":[{"id":"2","path":"Makefile","locked_at":"2019-08-14T20:49:21Z","owner":{"name":"slonopotamus"}}]}
Makefile        slonopotamus    ID:2
23:49:26.614832 trace git-lfs: filepathfilter: rewrite ".git" as "**/.git/**"
23:49:26.614843 trace git-lfs: filepathfilter: rewrite "**/.git" as "**/.git"
23:49:26.614875 trace git-lfs: filepathfilter: accepting "tmp"

Description

Look at "locked_at" timestamps. When lock it just created, Gitea returns timestamp with nanosecond precision: 2019-08-14T20:49:21.392551447Z. But when I am listing locks later, timestamp only has second precision: 2019-08-14T20:49:21Z

Expected: lock is always returned with same timestamp precision via LFS API. Also, LFS protocol spec clearly says that timestamp needs to have second precision.

P.S. If this bug came with code from lfs-test-server, please tell me so I open a bugreport there too.

@slonopotamus slonopotamus changed the title LFS locks "locked_at" has inconsistent precision LFS locks "locked_at": inconsistent precision + protocol violation Aug 14, 2019
@slonopotamus slonopotamus changed the title LFS locks "locked_at": inconsistent precision + protocol violation LFS locks "locked_at": inconsistent precision + LFS spec violation Aug 14, 2019
@sapk
Copy link
Member

sapk commented Aug 14, 2019

The problem seems to come from that list have timestamp based on stored in database and POST the lock details come from the object unaltered so with nanosecond precision.
The fix (in coming) is to adjust func (l *LFSLock) APIFormat() *api.LFSLock to fix the time precision.

@lunny lunny added the type/bug label Aug 14, 2019
@lafriks lafriks added this to the 1.9.2 milestone Aug 15, 2019
@go-gitea go-gitea locked and limited conversation to collaborators Nov 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants