來自FileOutputStream.close（）的設備不適當的ioctl

Question

我有一些代碼使用FileOutputStream將一些首選項保存到文件。這是標準的代碼，我已經寫了一千遍：

我們的用戶的

FileOutputStream out = new FileOutputStream(file); 
try { 
    BufferedOutputStream bos = new BufferedOutputStream(out); 
    try { 
     store(bos, comments); 
    } finally { 
     bos.close(); 
    } 
} finally { 
    out.close(); 
} 

一種是close()通話過程中報告在Linux下面的錯誤。

java.io.IOException: Inappropriate ioctl for device 
    at java.io.FileOutputStream.close0(Native Method) 
    at java.io.FileOutputStream.close(FileOutputStream.java:341) 
    at java.io.FilterOutputStream.close(FilterOutputStream.java:160) 

有誰知道，如果這時候用錯-d32或-d64參數不正確啓動JVM只發生（如在this question），還是有可能別的事情嗎？

Answer 1

Java的close()方法是圍繞OS native close()的薄包裝;它會將本地錯誤代碼轉換爲異常。

鏈接到的文檔對可能導致接近失敗的原因相對模糊不清，並指出寫入過程中的錯誤可能通過close報告，並且「這尤其可以通過NFS觀察到......」。

因此，要進行調試，我首先要查看文件的名稱以及文件的存儲位置。我不會過分強調「不適當的ioctl」的非關閉（）相關命中。

Answer 2

我很確定你對32/64位模式的想法是正確的。幾年前，我們在嵌入式設備上工作時遇到了這個問題，該錯誤源於我們用來與pci交換機對話的庫，並且庫不支持64位ioctls。

我的建議，如果你真的想要它的底部，我已經使用這種技術來調試jni代碼。在java應用程序中設置一個斷點，然後使用gdb連接到進程。然後，您可以在gdb中設置一個斷點來監視設備上的ioctl。查看哪個請求被髮送到設備並驗證它是否正確支持該體系結構。

如果文件輸出流正在從文件系統文件中讀取而不是另一種類型的設備文件。那麼這可能是selinux的一個問題，或者像chroot環境那樣的某種虛擬化，就像下面的鏈接一樣。

此鏈接可能指向正確的方向。正是有了chroot環境問題
http://us.generation-nt.com/answer/sndctl-tmr-timebase-tcgets-help-170073041.html

也絕對檢查他們所運行的JRE，是OpenJDK的還是它的Sun Java？我對舊的gcc jdk java有一些非常奇怪的怪癖，這可能解釋了一些差異。