# N01 — NewFilePlugin Unix: memoryUnmap inverted condition, mapping leaks every call

Bug ref      : pharo-12 only (NewFilePlugin is new in pharo-12)
Severity     : HIGH (one VM mapping leaked per `NewFile_memoryUnmap` call)
File         : plugins/NewFilePlugin/src/unix/UnixFile.c
Lines (HEAD) : 295-306

## Problem

```c
PHARO_NEWFILE_EXPORT void
NewFile_memoryUnmap(NewFile_t *file)
{
    if(!file || file->memoryMapCount <= 0)
        return;

    --file->memoryMapCount;
    if(!file->memoryMapCount)        /* count IS 0 → returns without unmapping */
        return;

    munmap(file->memoryMapAddress, file->memoryMapLength);
}
```

The intent is reference counting: increment on each `memoryMap`, decrement
on each `memoryUnmap`, and finally `munmap` when the count reaches zero.
The condition is inverted: `if(!memoryMapCount) return;` triggers when
the count has just dropped to **zero** — exactly the moment when
`munmap` should be called. The result is that `munmap` is only reached
while the mapping is still referenced (count > 0), so it never actually
unmaps anything in practice. Every `NewFile_memoryUnmap` is a leak.

The Win32 sibling at `plugins/NewFilePlugin/src/win/Win32File.c:467-479`
does it the right way:

```c
--file->memoryMapCount;
if(file->memoryMapCount > 0)
    return;
UnmapViewOfFile(file->memoyMapAddress);
```

## Fix

Match the Windows logic.

```diff
diff --git a/plugins/NewFilePlugin/src/unix/UnixFile.c b/plugins/NewFilePlugin/src/unix/UnixFile.c
index bb7a747b0..6a7b72cad 100644
--- a/plugins/NewFilePlugin/src/unix/UnixFile.c
+++ b/plugins/NewFilePlugin/src/unix/UnixFile.c
@@ -299,7 +299,7 @@ NewFile_memoryUnmap(NewFile_t *file)
         return;
 
     --file->memoryMapCount;
-    if(!file->memoryMapCount)
+    if(file->memoryMapCount > 0)
         return;
 
     munmap(file->memoryMapAddress, file->memoryMapLength);
```

## Test plan

- Open a file, call `NewFile_memoryMap` once, then `NewFile_memoryUnmap`
  once. Before: `cat /proc/self/maps` after the unmap still shows the
  mapping. After: the mapping is gone.
- Map/unmap 10⁵ times in a loop on a small file; verify with `pmap` or
  `vmmap` that mappings do not accumulate.

## Risk notes

- This is a one-character fix (`!` → `> 0` and inverted return),
  matches the Windows sibling exactly, and cannot regress: the
  pre-existing behaviour was "never unmap," so no caller depends on
  munmap NOT being called.