Memory-sync mode still opens some files for writing
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 38/100
- Issue-Typ
- Bug
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Veraltet
- Tech-Stack
- c
- Bereich
- cli, operating-systems
Rechercherichtung
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.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
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.
- Vorherrschende Sprache
- C
- Sterne
- 1.2k
- Forks
- 152
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Entwicklungsumgebung
- Kein Dockerfile und keine Docker-Compose-Datei
- Keine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus void-linux/xbps
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 68/100
void-linux/xbps#475 ·
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 45/100
void-linux/xbps#701 ·
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 55/100
void-linux/xbps#700 ·
-
xbps-query -RX repository overridesEvtl. vergeben @outofsyncrs hat das vor 30 Tagen übernommen. Offenbug
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 45/100
void-linux/xbps#696 ·
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 52/100
void-linux/xbps#695 · 7 Kommentare ·
Alle Issues in void-linux/xbps
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
-
chore(gateway): emit INFO budget reserved/settled logs for proactivity v2 (chip task_2855f4ec)Offenbackend
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
BasedHardware/omi#20940 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
kovidgoyal/kitty#10625 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Feature Status: Needs Triage
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 73/100
Maintainer antworten meist innerhalb von 1 Tag