A Quadcap customer reports the following:

An exception is thrown whenever we run QED on SAMBA shares.  Is there 
any way we can get around this?

Here's what we see when we run QED on a Samba share mounted from a 
Solaris 2.7 server.  The problem disappears when we move QED to NTFS.

2003-11-05 16:58:09.816: [main] java.io.IOException
2003-11-05 16:58:09.846: [main] java.io.IOException: The mounted file system
does not support extended attributes
        at java.io.RandomAccessFile.setLength(Native Method)
        at
com.quadcap.sql.file.FileRandomAccess.checkCapacity(FileRandomAccess.java:127)
        at com.quadcap.sql.file.FileRandomAccess.write(FileRandomAccess.java:84)
        at com.quadcap.sql.file.RandomAccess.writeInt(RandomAccess.java:103)
        at com.quadcap.sql.file.LogBuffer.sync(LogBuffer.java:271)
        at com.quadcap.sql.file.LogBuffer.init(LogBuffer.java:110)
        at com.quadcap.sql.file.Logger1.init(Logger1.java:147)
        at com.quadcap.sql.file.Log1.init(Log1.java:231)
        at com.quadcap.sql.file.Log2.init(Log2.java:64)
        at com.quadcap.sql.file.Datafile.init(Datafile.java:432)
        at com.quadcap.sql.Database.init(Database.java:121)
        at com.quadcap.jdbc.JdbcDriver.connect(JdbcDriver.java:225)
        at java.sql.DriverManager.getConnection(DriverManager.java:512)
        at java.sql.DriverManager.getConnection(DriverManager.java:140)
        at ...


My research on this bug leads me to the Java Developer site,
and their bug: 4732964.   They closed their bug (state: CLOSED, WONTFIX),
stating that it was a Samba problem.    My customer is using an old
(2.0.6) version of Samba, but I can't find any record of this bug in
bugzilla, I'm entering it now.

I'm attaching the text of the 4732964 bug for your convenience:

Bug Id   	  4732964
Votes 	0
Synopsis 	can't start rmid when log directory is on mounted Samba network drive
Category 	java:rmi
Reported Against 	hopper-beta, mantis-rc
Release Fixed 	 
State 	Closed, will not be fixed
Related Bugs 	4697249, 4879656
Submit Date 	Aug 16, 2002
Description 	




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)


webbug virgilnl

Workaround 	

None.

Evaluation 	

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...

xxxxx@xxxxx 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.]

xxxxx@xxxxx 2003-06-24