[BUG] Interrupting an activation phase can lead to file_map.db corruption
— at Version 6
I interrupted DarwinPorts during an activation phase and it left me with a severely-truncated
file_map.db file. I'm guessing that DarwinPorts doesn't bother trapping that signal (I simply hit C) and I
hit it during the filemap save method. DarwinPorts should either trap the signal to clean up nicely, or
saving the file_map.db file should do an atomic save (i.e. save it in the temporary directory, then use an
OS-provided atomic swap of the temp file and the original file_map.db file - if no atomic swap method
exists for the given OS (I know Cocoa and Carbon provide atomic swap methods, but I don't know about
darwin), go ahead and swap the two non-atomically - it's still dangerous, but far less than saving over
file_map.db)
Change History (6)
Owner: |
changed from darwinports-bugs@… to pguyot@…
|
Resolution: |
→ fixed
|
Status: |
new →
closed
|
Milestone: |
→ MacPorts base bugs
|
Priority: |
Expected →
Normal
|
Version: |
1.0
|
Milestone: |
MacPorts base bugs →
MacPorts Future
|
Description: |
modified (diff)
|
Milestone: |
MacPorts Future
|
Indeed Kevin, we need atomic update of the filemap database since it's a critical component. BTW, POSIX requires rename(2) to be atomic.