来自FileOutputStream.close（）的设备不适当的ioctl [英] Inappropriate ioctl for device from FileOutputStream.close()

问题描述

我有一些代码可以使用 FileOutputStream 将一些首选项保存到文件中。这是我写过一千次的标准代码：

I have some code that saves some preferences to file using FileOutputStream. It is standard code I've written a thousand times:

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

我们的一位用户在<$ c期间在Linux上报告以下错误$ c> close（） call。

One of our users is reporting the following error on Linux during the close() call.

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启动JVM时是否发生这种情况或-d64参数（如此问题），或者是可能还有其他事情发生了？

Does anybody know if this ONLY happens when incorrectly launching the JVM with the wrong -d32 or -d64 parameter (like in this question), or is there possibly something else going on?

推荐答案

我很确定你对32/64位模式的想法是正确的。我们几年前在嵌入式设备上遇到过这个问题，错误源于我们用来与pci交换机通信的库，而且库不支持64位ioctl。

I am pretty sure you are correct with the 32/64 bit mode idea. We had this issue a couple of years ago working on an embedded device, the error was stemming from a lib that we were using to talk to a pci switch and the library did not support 64 bit ioctls.

我的建议如果你真的想要深究它并且我已经使用这种技术来调试jni代码。在java应用程序中设置断点，然后使用gdb附加到进程。然后，您可以在gdb中设置断点以监视设备上的ioctl。查看正在向设备发送的请求，并验证它是否正确支持该体系结构。

My suggestion if you really want to get to the bottom of it and I have used this technique to debug jni code. Set a break point in the java app, then use gdb to attach to the process. You can then set a break point in gdb to watch for the ioctl on the device. See which request is being sent to the device and verify that it is correctly support for that architecture.

如果fileoutput流正在从文件系统文件而不是其他类型的设备文件中读取。那么这可能是selinux的问题，或者像chroot环境那样的某种虚拟化，如下面的链接所示。

If fileoutput stream is reading from a filesystem file and not another type of device file. Then this is probably a problem with selinux, or some kind of virtualization like a chroot environment as in the following link.

此链接可能指向正确的方向。这是chroot的问题

http://us.generation-nt.com/answer/sndctl-tmr-timebase-tcgets-help-170073041.html

This link may point in the right direction. It was a problem with the chroot
http://us.generation-nt.com/answer/sndctl-tmr-timebase-tcgets-help-170073041.html

还明确检查他们正在运行的jre，是openjdk还是sun java？我对旧的gcc jdk java有一些非常奇怪的怪癖，这可能解释了一些差异。

Also definitely check the jre they are running, is it openjdk or is it sun java? I have had some very odd quirks with the older gcc jdk java and this may explain some of the discrepancies.

这篇关于来自FileOutputStream.close（）的设备不适当的ioctl的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！