我有一些代码，使用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)
有没有人知道这是唯一发生错误地启动JVM的错误-d32或-d64参数（如在这个问题 ），或者有可能还有其他事情？
我非常肯定你对32/64位模式的想法是正确的。 几年前，我们在嵌入式设备上工作时遇到了这个问题，错误源于我们用来与pci交换机通信的库，而库不支持64位ioctl。
我的建议，如果你真的想到底，我已经使用这种技术来调试jni代码。 在java应用程序中设置一个断点，然后使用gdb连接到进程。 然后，您可以在gdb中设置一个断点来监视设备上的ioctl。 查看哪个请求被发送到设备，并验证它是否正确支持该体系结构。
如果文件输出流正在从文件系统文件中读取而不是另一种类型的设备文件。 那么这可能是selinux的一个问题，或者像chroot环境那样的虚拟化，就像下面的链接一样。
这个链接可能指向正确的方向。 这是chroot的一个问题
http://us.generation-nt.com/answer/sndctl-tmr-timebase-tcgets-help-170073041.html
也绝对检查他们正在运行的jre，是openjdk还是太阳java？ 我有一些非常古怪的gcc jdk java怪癖，这可能解释一些差异。
Java的close()方法是操作系统本地close（）方法的一个简单封装。 它会将本地错误代码转换为异常。
链接到的文档是相对模糊的什么可能会导致接近失败，注意到在编写过程中的错误可能会报告近，而且“这尤其可以观察到NFS …”。
所以，为了调试，我首先看看文件的名称，以及为这个特定用户存储文件的位置。 我不会过分强调“不适当的ioctl”的非关闭（）相关的命中。