Bug 725 - SetEndOfFile returns wrong value on Samba shares
Summary: SetEndOfFile returns wrong value on Samba shares
Alias: None
Product: Samba 2.2
Classification: Unclassified
Component: File Services (show other bugs)
Version: 2.2.8a
Hardware: All All
: P3 normal
Target Milestone: ---
Assignee: Gerald (Jerry) Carter (dead mail address)
QA Contact:
URL: http://developer.java.sun.com/develop...
Depends on:
Reported: 2003-11-06 13:38 UTC by Stan Bailes
Modified: 2004-02-17 08:56 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Stan Bailes 2003-11-06 13:38:18 UTC
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.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

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)


Windows NT version 4.0

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.

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.

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
	at sun.rmi.log.ReliableLog.recover
	at sun.rmi.server.Activation.startActivation
	at sun.rmi.server.Activation.main

This bug can be reproduced always.

use a log directoy that is local
(Review ID: 160581)

webbug virgilnl




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

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");

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

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
Comment 1 Tim Potter 2003-11-06 14:15:34 UTC
If you can post a samba logfile at debug level 10 of the request that is
returning the error it would be very helpful.
Comment 2 Stan Bailes 2003-11-07 12:34:19 UTC
I've forwarded the log request to my customer, and here's
his response:

> Unfortunately, our system admin guy is no longer working here,
> so we probably can't reconfigure Samba to generate logs.

Though the testcase in the JDC bug report seems like it should
be pretty easy to reproduce.  SetEndOfFile(8) should do the trick.
Comment 3 Gerald (Jerry) Carter (dead mail address) 2004-02-17 08:56:07 UTC
Sorry, but the 2.2 is not under development any longer.
If you can reproduce this bug against the latest 3.0 release, 
please reopen this bug and change the version in the report.