Aros/開發者/文件/處理程式/FFS

當插入新的卷時，ACTION_INHIBIT/FALSE 被髮送到該 trackdisk.device 的 FFS。如果 FFS 探測磁碟時，不匹配舊卷，則會在 DOS 列表中建立一個新的 DOS 卷。誰會發送 ACTION_INHIBIT 包？我認為處理程式會響應來自裝置或 Intuition 的磁碟更改通知。目前情況就是這樣。但是，如果多個處理程式連線到同一個裝置（例如，一個針對彈出卷（帶有開啟的鎖）的 FFS 處理程式，以及一個當前在裝置上執行的 FAT 處理程式），則我認為磁碟更改通知應該透過來自處理程式外部的 DOS 包發出。

否則，FFS 和 FAT 處理程式都會嘗試在每次磁碟更改時開啟裝置，對嗎？

[在 AOS 上有一個有趣的測試。準備一堆軟盤，分別儲存 800K a.txt、b.txt、c.txt 等檔案，並在每個軟盤上執行 `MORE DF0:a.txt` 等操作，然後彈出軟盤，插入新的軟盤，並在新的 CLI 中執行 `MORE DF0:b.txt` 等操作，並保持所有這些 MORE 處於開啟狀態。我想看看會發生什麼。] 我認為，直到其中一個 More 任務需要讀取更多資料時，才會發生任何事情。然後，會出現一個“請在 DF0 裝置中插入“軟盤名稱”卷”的請求。檔案控制代碼將與特定的卷相關聯，即使它們最初是透過裝置路徑開啟的。

但是 trackdisk.device 始終由同一個檔案系統處理程式提供服務。如果你將 FAT 和 FFS 都安裝到同一個 trackdisk.device，可能會發生奇怪的事情。這就是為什麼需要 MultiFS 之類的東西（參見 AmiNet 上的 mfs21.lha）。MultiFS 充當 FFS 和 FAT 檔案系統的代理，在磁碟更改後執行磁碟格式檢查，然後再將 DOS 包傳遞給相應檔案系統的處理程式。Partition.library 可以發揮 MultiFS 的作用，而無需任何代理。正如你所提到的，trackdisk.device 的情況之所以複雜，是因為通常單個處理程式會靜態繫結到其每個單元。分割槽介質以及動態分配的處理程式更容易處理（即便如此，我還是懷疑將處理程式動態分配給 trackdisk.device 可能是 MultiFS 基於代理的方法的另一種可行方案）。

我建議使用類似的方法。對於每個裝置，存在一個代理（可能是 DOS 包代理，也可能是裝置 I/O，我需要進行試驗），它在磁碟更改後確定要傳送給哪個檔案系統型別。

一旦確定，所有未來的資料包/I/O 都將傳送到相應的位置。

我目前傾向於使用 DOS 包代理而不是裝置代理，因為在處理丟失卷情況以及排隊 I/O 而不是簡單地將其丟棄時，這（目前）似乎是一個更清晰的實現。

除了我認為，具有相同名稱的多個卷可以共存，而無需為它們中的任何一個偽造新名稱。你說得對。雖然 DOS 裝置必須是唯一的，但 DOS 卷沒有這樣的限制（當然，這就是 FindDosEntry() 接受 DosList 引數的原因...）。但是，DLT_DEVICEs 必須唯一，並且能夠正確處理 ACTION_DIE，並將它們的 dol_Task 設定為 BNULL，以支援彈出和替換備用檔案系統。然後，如果處理程式 *不能* 處理 ACTION_DIE（例如，存在開啟的鎖），則需要在將新的檔案系統任務連線到裝置之前，向其傳送 ACTION_INHIBIT。

這一切都取決於我們如何處理以下使用者案例：為了以通用方式支援可彈出、已分割槽的介質，並檢測到舊介質（仍有執行的處理程式）何時返回，以便不會載入新的、相互競爭的處理程式。

使用者插入一個 FAT32 裝置，從該裝置複製一個檔案，然後彈出裝置。
使用者插入一個 RDB(FFS) 裝置，執行一個程式，該程式開啟該裝置上的一個數據庫檔案。在檔案仍處於開啟狀態時，裝置被物理彈出。
然後使用者插入一個 MBR(FAT32,FFS) 裝置，其中 FAT32 的卷名與之前的 RDB(FFS) 裝置相同，但（顯然）內容不同。FFS 分割槽是一個新的名稱。

1.a) No locks are held, so this should be the simple case. 
1.a.1) Filesystem handler gets sent ACTION_DIE, since it has no locks in the dl_LockList for that handler.
1.a.2) Filesystem is dismounted
1.b) What happens if the handler refuses to ACTION_DIE?
1.c) What happens if the handler refuses to even ACTION_INHIBIT?

2.a) A lock is held. What happens?
2.a.1) Does a requester pop up on the next action to that device?
2.a.2) Do we return errors to the open applications on read/write/etc?
2.a.3) Do we prohibit any other device from being recognized until the original volume is reinserted? 
2.b) Do we keep that handler task running?
2.b.1) For how long? Until all its locks are closed (due to error handling by the application)? 
2.c)  Do we need some sort of iconography in Wanderer/Workbook to let the user know what volumes are 'in use' and should not be ejected?

3.a) Should we assume the OS is smart enough to recognize this case?
3.a.1) Should the OS reject the volume(s)?
3.a.2) Fake a new name for the volume(s) in conflict? (ie 'FooBar.1'?)
3.b) What changes to handlers (if any) are needed to support 3.a?
3.c) Should there be Wanderer/Workbook iconography for missing volumes?