Re: [RFR] man://manpages-l10n/mmap.2.po [5/5]
Hallo Helge,
#. type: Plain text
#: archlinux debian-buster debian-unstable fedora-rawhide mageia-cauldron
msgid ""
"The I<st_ctime> and I<st_mtime> field for a file mapped with B<PROT_WRITE> "
"and B<MAP_SHARED> will be updated after a write to the mapped region, and "
"before a subsequent B<msync>(2) with the B<MS_SYNC> or B<MS_ASYNC> flag, if "
"one occurs."
msgstr ""
"Das Feld I<st_ctime> und I<st_mtime> für eine mit B<PROT_WRITE> und "
"B<MAP_SHARED> gemappte Datei wird nach einem Schreibzugriff auf den gemappte "
"Bereich und vor dem nachfolgenden B<msync>(2) mit den Schalter B<MS_SYNC> "
"oder B<MS_ASYNC>, falls dieser erfolgt, aktualisiert."
auf den gemappte Bereich → auf den gemappten Bereich
#. type: SS
#: archlinux debian-buster debian-unstable fedora-rawhide mageia-cauldron
#, no-wrap
msgid "Huge page (Huge TLB) mappings"
msgstr "Mappings Großer Seiten (Huge TLB)"
Großer Seiten → großer Seiten
#. type: Plain text
#: archlinux debian-buster debian-unstable fedora-rawhide mageia-cauldron
msgid ""
"POSIX specifies that the system shall always zero fill any partial page at "
"the end of the object and that system will never write any modification of "
"the object beyond its end. On Linux, when you write data to such partial "
"page after the end of the object, the data stays in the page cache even "
"after the file is closed and unmapped and even though the data is never "
"written to the file itself, subsequent mappings may see the modified "
"content. In some cases, this could be fixed by calling B<msync>(2) before "
"the unmap takes place; however, this doesn't work on B<tmpfs>(5) (for "
"example, when using the POSIX shared memory interface documented in "
"B<shm_overview>(7))."
msgstr ""
"POSIX spezifiziert, dass das System immer jede teilweise gefüllte Seite am "
"Ende des Objektes mit Nullen auffüllen muss und dass das System niemals "
"Änderungen an dem Objekt hinter seinem Ende schreibt. Unter Linux verbleiben "
"sämtliche geschriebenen Daten in solchen Teilseiten nach dem Ende des "
"Objektes im Seitenzwischenspeicher, selbst nachdem die Datei geschlossen und "
"entmappt wurde und selbst obwohl die Daten niemals zu der Datei selbst "
"geschrieben wurden, könnten nachfolgende Mappings die veränderten Inhalte "
"sehen. In einigen Fällen könnte dies durch einen Aufruf von B<msync>(2) "
"bevor das Aufheben des Mappings stattfindet, behoben werden, allerdings "
"funktioniert dies nicht auf B<tmpfs>(5) (beispielsweise beim Einsatz der "
"POSIX-Schnittstelle für gemeinsamen Speicher, wie in B<shm_overview>(7) "
"dokumentiert)."
Aufruf von B<msync>(2) bevor das Aufheben
→
Aufruf von B<msync>(2), bevor das Aufheben
Gruß Mario
Reply to: