Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

save_zip can emit one companion twice under two spellings when the source folder folds case and the temp dir does not

Aperta
#35 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
72/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Tranquilla
Stack tecnologico
python
Ambito
tooling

Direzione di ricerca

Inizia in src/sil_lift/_zip.py, in save_zip, e segui _write_zip per capire come i file companion copiati e renderizzati entrano nella directory di staging. Riproduci le condizioni di una sorgente con case-folding e di un TMPDIR case-sensitive descritte nell’Issue, quindi verifica che l’archivio contenga un solo membro .lift-ranges con i byte renderizzati e nessuna variante obsoleta di maiuscole/minuscole.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug

Lexicon.save_zip() can produce an archive containing the same .lift-ranges twice — once stale, once current — under names differing only in case.

Preconditions

Both must hold, which is why this is not seen in ordinary use:

  1. The LIFT folder is on a case-folding filesystem, and its .lift and companion disagree in case (Dict.LIFT beside Dict.lift-ranges). This is what makes RangesFile.path carry a spelling that is not the on-disk name — _existing_file returns the candidate's spelling when the exact stat succeeds, and on a folding filesystem it succeeds for a case variant.
  2. TMPDIR is on a case-sensitive filesystem. On macOS that is a case-sensitive APFS volume; on Linux, a LIFT folder on ciopfs / exfat / casefold-enabled ext4 with /tmp on ext4.

Normally these are the same filesystem — the divergence needs folding, and staging happens on the same machine — so the second write lands on the first file and nothing goes wrong.

Mechanism

save_zip (src/sil_lift/_zip.py) stages into a TemporaryDirectory, copies the whole source package in, then overwrites the rendered files by name:

shutil.copytree(source_root, content, dirs_exist_ok=True)   # brings in Dict.lift-ranges
...
name = ranges_file.path.name if ranges_file.path is not None else Path(key).name
(content / name).write_bytes(render_ranges_document(ranges_file))   # writes Dict.LIFT-ranges

_write_zip then walks the staging directory, so members come from the filesystem rather than from the names. Where staging folds case, the second write overwrites the copied file and leaves its directory entry alone: one file, one member, correct bytes. Where staging does not fold, it creates a second file, and the archive gets both — the stale copytree'd bytes under the on-disk spelling and the rendered bytes under the href's spelling.

On read-back the duplicate is not rejected: _select_lift_member only guards against multiple .lift members, and two case-variant .lift-ranges are resolved the way any such folder is — one wins.

Fix options

  • Narrow, in save_zip: before writing, look for a file already in staging whose name folds onto name and write to that spelling instead. Keeps the change local to packaging.
  • At the root, in _resolve_ranges: hand RangesFile.load the canonical path so RangesFile.path always matches what is on disk. Tempting one-liner, but the canonical path is absolute and symlink-collapsed, so it changes a public attribute's value and what RangesFile.save() targets for every caller — a much wider blast radius than the defect.

The first looks right; the second is worth ruling out deliberately rather than by omission.

Notes

Pre-existing: _resolve_ranges passed the candidate's spelling to RangesFile.load before #19 as well. Split out of review discussion on #19, which kept its scope to companion resolution.

Lingua principale
Python
Stelle
1
Fork
0
Merge medio
11g 3h
PR unite (30g)
6

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di sillsdev/python-sil-lift

Tutte le issue di sillsdev/python-sil-lift

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.