Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
JRuby raises IOError instead of specific error if File.rename(a,b) fails due to hidden filesystem #5318
This is running in a FreeBSD jail where /tmp is a tmpfs file system, current path is in /home, which is under the root filesystem, and enforce.statfs=2 flag is set for the jail, so Files.getFileStore fails with Mount point not found in fstab if one or both paths are within /tmp. This difference causes bundler to fail.
While @bgalbrecht was filing this I poked around a bit and found the cause.
This "Mount point not found in fstab" error is actually from OpenJDK code used by the Paths subsystem to get the filesystem for a given Path.
The logic in OpenJDK differs from that in CRuby in that while the latter does a statfs and uses the results therein to compare filesystems, the former gets a list of all mounted filesystems and iterates over them to find one with a device matching the Path in hand. If it does not find that device listed as a mounted filesystem, it throws this lovely error as a dumb IOException that we turn into a dumb IOError.
It happens in this case because @bgalbrecht is running in a FreeBSD jail, which apparently does not expose the mount point of /tmp to jailed processes, and therefore OpenJDK refuses to return any filesystem information for any jailed /tmp file.
The logic of rename(2) on BSD comes into play here, since it appears that's what CRuby calls. The man page just says this about how EXDEV might be raised:
The link named by new and the file named by old are on different logical devices (file systems). Note
This says nothing about files on the same filesystem that doesn't have an fstab entry, but @bgalbrecht's original output shows that CRuby is unable to rename a file from a location in /tmp to a location in /tmp, so it appears that BSD rename has similar behavior to OpenJDK here.
There are two options for fixing this:
It appears the ATOMIC_MOVE operation on java.nio.file.Files.move might be the behavior of native
This would be preferable to adding and depending on another native function binding.