Memory-sync mode still opens some files for writing
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 4/5
- Tempo estimado
- 3-5 dias
- Facilidade para iniciantes
- 38/100
- Tipo de issue
- Bug
- Clareza
- Razoavelmente clara
- Status de atividade
- Estagnada
- Stack de tecnologia
- c
- Domínio
- cli, operating-systems
Direção de pesquisa
Start with lib/download.c around the referenced retry branch and reproduce xbps-install with -MS both with and without root, comparing the saved strace output if available. Trace why memory-sync opens x86_64-repodata.part for writing and why the failure reports both an error and “Success”; done means memory-sync avoids unnecessary writes and reports the underlying failure accurately.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
When using xbps-install with flags -MS, xbps will open the db (/var/db/xbps/) in write mode if a remote repo has changed since the last real sync.
This is apparent when running the command without root, where the openat() call fails. It also seems that when run as root, the same command does not actually use the opened file, as further runs of it without root will still present the error.
Using strace, the error (which I think comes from lib/download.c) seems to be this:
openat(AT_FDCWD, "x86_64-repodata.part", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0644) = -1 EACCES (Permission denied)
It is in the retry branch of that if though, so maybe there's also an error before it.
There's also a secondary bug; this failure (both sync modes without root) causes a message that both claims failure and success
ERROR: [reposync] failed to fetch file `https://privatereporedacted/x86_64-repodata': Success
[DEBUG] [rpool] `https://privatereporedacted' failed to fetch repository data: Success
(the error line is part of normal output)
I have saved the full strace output of memorysync with and without root, and rootless normal sync. I can provide those if needed but not publicly over github.
- Linguagem predominante
- C
- Estrelas
- 1.2k
- Forks
- 152
- Métricas de merge de PRs
- Nenhum PR com merge em 30d
Preparar o ambiente
- Sem Dockerfile nem arquivo Docker Compose
- Sem modelo de pull request
- Ler o guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de void-linux/xbps
-
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 68/100
void-linux/xbps#475 ·
-
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 45/100
void-linux/xbps#701 ·
-
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 55/100
void-linux/xbps#700 ·
-
xbps-query -RX repository overridesTalvez já em andamento @outofsyncrs assumiu há 31 dias. Abertabug
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 45/100
void-linux/xbps#696 ·
-
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 52/100
void-linux/xbps#695 · 7 comentários ·
Todas as issues de void-linux/xbps
Issues semelhantes
-
Warps 4 unit tests (raalloc)Abertaenhancement good first issue
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 66/100
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 72/100
Mantenedores costumam responder em até 1 dia
-
Policy query leaks host primary block (BSL_PrimaryBlock_deinit skipped) on two early-exit pathsAberta
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 72/100
NASA-AMMOS/BSL#355 ·
Mantenedores costumam responder em até 1 dia
-
bug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
arancormonk/dsd-neo#660 ·
Mantenedores costumam responder em até 1 dia
-
[Bug]: remote-ls --updates reports up-to-date OCI refs because it ignores deployed Alt-idTalvez já em andamento @Joao-kouznetz assumiu hoje. Aberta
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 72/100
Mantenedores costumam responder em até 1 dia