改了三次,存檔三次,重啟三次。每次打開都是預設值,就像從沒動過。
這就像在社區公告欄貼便利貼——管委會的人每天早上會清掉沒有章戳的東西。你貼再多次都沒用,要讓公告留下來,得填申請表、蓋官方章,才算數。
你以為你有寫入權
那個設定檔可以直接用 vim 打開,改完存檔沒報錯,檔案權限也沒問題。看起來一切正常。重新啟動服務,設定又回到初始狀態。檢查檔案內容,你寫的東西全不見了。
第一次以為是快取問題。第二次懷疑是權限不對。第三次才意識到:這份文件根本不屬於你。
它屬於系統主程式。守護進程在啟動時會根據自己的 schema 重新產生這個檔案。你的手動修改在那個瞬間就被覆蓋了,不是因為你寫錯,是因為你壓根沒有寫入的主權。
讀取權不等於控制權
很多系統會把設定檔放在看得到的地方,讓你覺得「既然我能開、能改、能存,那就是我的」。但實際上這個檔案只是程式內部狀態的一個映射,真正的來源在別處。
程式啟動時不是讀取你修改後的版本,而是從自己的內部資料庫或預設模板重新生成一份。你的修改只是暫時存在磁碟上,下次重啟就被新生成的版本覆蓋。
正確做法是用系統提供的 CLI 指令操作。這些指令會呼叫內部 API,把設定寫到程式真正認得的地方。格式正確,不會被覆蓋,也不會因為你手動編輯時少打一個逗號就整個爆掉。
為什麼系統要這樣設計
因為設定檔的格式和結構可能會隨版本變動。如果讓使用者直接編輯,程式升級後舊格式的設定可能會導致啟動失敗。由程式自己產生設定檔,可以確保格式永遠符合當前版本的 schema。
另一個原因是防止手動編輯造成的錯誤。少一個括號、多一個空格、編碼不對,都可能讓整個服務起不來。透過 CLI 操作,程式會在寫入前驗證格式,減少出錯機會。
你有讀的權利,但沒有寫的主權。這不是 bug,是設計。
怎麼知道哪些檔案不該直接改
通常文件會註明,但很多時候沒人看文件。比較實際的判斷方式是:如果這個設定檔的路徑在系統服務的管理目錄下,而不是在 /etc 或使用者家目錄,那它很可能是程式自己生成的。
另一個線索是檔案開頭有沒有註解寫「DO NOT EDIT THIS FILE MANUALLY」。如果有,那就真的別碰。
最後一個方法是看有沒有對應的 CLI 工具。如果官方文件裡所有設定範例都是用指令而不是直接編輯檔案,那答案已經很明確了。
改了三次之後,你終於搞清楚一件事:這個檔案,你只是路過的讀者,不是它的主人。
— 邱柏宇
延伸閱讀
The Config File You Don’t Actually Own
Three edits. Three saves. Three reboots. Every time you open it, default values stare back at you like nothing ever happened.
It’s like putting up a sticky note on a community bulletin board—the management clears anything without an official stamp every morning. You can post it a hundred times, but unless you fill out the form and get it approved, it won’t stay.
The illusion of write access
The config file opens in vim just fine. You edit it, save it, no errors. File permissions look good. Everything seems normal. Then you restart the service and the settings revert to their initial state. Check the file—your changes are gone.
First time, you think it’s a cache issue. Second time, maybe permissions. Third time, it hits you: this file doesn’t belong to you.
It belongs to the main program. The daemon regenerates this file from its own schema on startup. Your manual edits get overwritten in that moment—not because you wrote something wrong, but because you never had write sovereignty in the first place.
Read access isn’t control
Many systems put config files in visible locations, making you think “if I can open it, edit it, and save it, it’s mine.” But this file is just a projection of the program’s internal state. The real source lives elsewhere.
On startup, the program doesn’t read your modified version—it regenerates the file from its internal database or default template. Your edits exist temporarily on disk, only to be replaced by a fresh copy next reboot.
The correct approach is to use the system’s CLI commands. These invoke internal APIs that write settings to where the program actually reads from. Format guaranteed correct, won’t be overwritten, and you won’t crash the entire service because you missed a comma.
Why design it this way
Because config file formats and structures change between versions. If users edit directly, upgrades could break with incompatible old formats. When the program generates its own config, the format always matches the current schema.
Another reason: preventing manual editing errors. Missing bracket, extra space, wrong encoding—any of these can prevent the service from starting. CLI operations validate format before writing, reducing error chances.
You have read rights but not write sovereignty. This isn’t a bug. It’s design.
How to tell which files not to touch
Documentation usually says so, but who reads documentation. A practical heuristic: if the config file lives in the system service’s management directory rather than /etc or a user home directory, it’s probably auto-generated.
Another clue is a comment at the top saying “DO NOT EDIT THIS FILE MANUALLY.” If it’s there, believe it.
Final method: check for corresponding CLI tools. If official docs show all configuration examples using commands rather than direct file editing, the answer is clear.
After three failed attempts, you finally understand: this file isn’t yours to own. You’re just passing through.
— 邱柏宇