Name: nt126004 Date: 08/16/2002
FULL PRODUCT VERSION :
java version "1.4.1-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-beta-b14)
Java HotSpot(TM) Client VM (build 1.4.1-beta-b14, mixed mode)
FULL OPERATING SYSTEM VERSION :
Windows NT version 4.0
EXTRA RELEVANT SYSTEM CONFIGURATION :
All our Windows NT computers use a mounted network drive
(through Samba) for their development tasks. The network
drive is on a Solaris 8 server.
A DESCRIPTION OF THE PROBLEM :
When starting the RMI activation deamon and specifying a
log directory that is a Samba mounted network drive the
rmid fails with a message describing it can't find some
sort of message.
rmid -log <some non local drive>
This only happens on Windows NT, for an rmid on a Linux
workstation is able to write its state to a remote (Samba)
mounted partition.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. mount a samba drive on Windows NT, e.g. P:
2. start rmid with log option that points to mounted
network drive, rmid -log P:\log
3. await the message
Activation.main: an exception occurred: The system cannot
find message for message number 0x%1
in message file for %2
java.io.IOException: The system cannot find message for
message number 0x%1
in message file for %2
at java.io.RandomAccessFile.setLength(Native Method)
at sun.rmi.log.ReliableLog.recoverUpdates
(ReliableLog.java:686)
at sun.rmi.log.ReliableLog.recover
(ReliableLog.java:208)
at sun.rmi.server.Activation.startActivation
(Activation.java:144)
at sun.rmi.server.Activation.main
(Activation.java:1977)
REPRODUCIBILITY :
This bug can be reproduced always.
CUSTOMER WORKAROUND :
use a log directoy that is local
(Review ID: 160581)
======================================================================
- duplicates
-
JDK-4879656 RegTest java/rmi/activation/ActivationGroupDesc/useExecPolicy/UseDefaultExecPoli
-
- Closed
-
- relates to
-
-
- Closed
-
I was able to reproduce a very similar failure, except that the IOException detail message was instead
The mounted file system does not support extended attributes
rmid was run from machines running NT 4 service packs 5 and 6 with the log in a Samba-mounted directory using Hopper RC build 19 as well as J2SE 1.4, 1.3.1, and 1.2.2 (so this is NOT a Hopper regression, nor does it appear to be HotSpot-specific).
This looks related to java/classes_io bug 4697249, which was closed as a (presumed) configuration error.
I was able to narrow down the failure to a very small test case with a particular input:
import java.io.RandomAccessFile;
public class SetLength {
public static void main(String[] args) throws Exception {
RandomAccessFile raf = new RandomAccessFile("raf", "rw");
raf.setLength(Integer.parseInt(args[0]));
}
}
Executing this program (with the current working directory on a Samba-mounted drive) succeeded for all non-negative argument values that I tried, except for 8, which produced an java.io.IOException with the same detail messages as above. Even with an argument of 8, the file's length was successfully set to 8, but the RandomAccessFile.setLength invocation threw the java.io.IOException anyway.
When executing this test case on a drive that was shared by a Windows 95 machine, this exception was not thrown trying to set the file's length to 8, so the problem appears possibly specific to a Samba-exported file system (perhaps even a particular version of Samba?).
It just so happens that 8 is the length that rmid will try to truncate a freshly-created log file to (because an empty log file just contains the major and minor version numbers, which occupy eight bytes) after going through the update recovery process.
The phenomenon seems peculiar indeed...
###@###.### 2002-08-19
Consultation with the java.io team has concluded that this behavior is a Samba bug exposed through use of the Windows file APIs, not a bug in the Java implementation, so we are closing this bug as "will not fix".
In particular, a Windows C program that attempts the same action as RandomAccessFile.setLength(8) on a Samba-mounted file observes an erroneous (zero) return from its call of the Windows SetEndOfFile function, even though the function call has performed the requested operation (setting the file's length to the current position of the file pointer, 8). [A subsequent call to the Windows GetLastError function returns the error code associated with the message described above.] This Windows C program observes a successful (non-zero) return from its SetEndOfFile function call if the file is on a local drive, or if the current position of the file pointer is anything but 8. [The native implementation of RandomAccessFile.setLength doesn't do anything unusual for Samba-mounted files (it uses the same Windows file APIs regardless) or for the argument value of 8.]
###@###.### 2003-06-24