Comment 1 Rafael Chaves 2003-11-13 13:34:57 EST

Probably a duplicate of bug 44735.

Please try running the test case in bug 44487 comment 9, passing as argument a 
samba-based file location, and tell us what happens.

Comment 2 Adrian Newby 2003-11-13 15:34:26 EST

running this ...

java TestLock /Volumes/DEVELOPMENT/adrian/workspace/.metadata/.lock

produces this ...

trying to acquire lock once
Exception in thread "main" java.io.IOException: Operation not supported
        at sun.nio.ch.FileChannelImpl.lock0(Native Method)
        at sun.nio.ch.FileChannelImpl.tryLock(FileChannelImpl.java:773)
        at java.nio.channels.FileChannel.tryLock(FileChannel.java:967)
        at TestLock.acquireLock(TestLock.java:8)
        at TestLock.main(TestLock.java:14)

Comment 3 Adrian Newby 2003-11-13 15:37:20 EST

JVM info:

java version "1.4.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-99)
Java HotSpot(TM) Client VM (build 1.4.1_01-27, mixed mode)

Comment 4 Andre Weinand 2003-11-14 08:28:06 EST

If this turns out to be a bug in Apple's Java implementation, please let me know.
I will file a radar bug.

Comment 5 Rafael Chaves 2003-11-14 10:05:14 EST

It is likely a duplicate of bug 44735, since the Java VM is the same (isn't it,
Adrian?).

It seems your current settings do not allow locking files in the Samba-based
file system (and your old settings before the upgrade allowed that).
If you can't/don't know how to restore the old behaviour, the workaround is to
disable the metadata lock file, what will allow you to start, but will leave you
unprotected against accidentally running multiple instances of Eclipse on the
same workspace, what may cause metadata corruption. To disable the lock file,
you need to specify:

eclipse <all-other-args> -vmargs -Dorg.eclipse.core.runtime.ignoreLockFile

So, Adrian, can you tell any difference in the Samba-related settings between
your previous setup and the current one?

Comment 6 Adrian Newby 2003-11-14 13:05:19 EST

Need a point of clarification here:

I upgraded the Mac OS from Jaguar to Panther.  This moved Samba from 2.2.7a up to 3.x.  Since it's 
conceivable that the local Samba client software upgrade might have changed the environment, I'll 
look into any config changes associated with this move.  If I understand yyou correctly, I'm looking 
for changes in locking behavior.

However, the location of the Eclipse workspace itself is a Samba-exposed UNIX file system on a 
remote machine.  Nothing in this environment changed so I won't be able to discover any 
differences there.

Before I look at the client-side Samba, though, I'll go back and confirm that the behavior is fine 
with 3.0M3.  It strikes me that if I can show a functional difference between 3.0M3 and 3.0M4 in 
the exact same environment, that might be helpful.  Yes?

Comment 7 Adrian Newby 2003-11-14 13:21:32 EST

3.0M3 does not show the problem behavior.  It creates and removes the .lock file as you would 
expect.

I will continue to probe my local Samba configuration as mentioned in my earlier commment but 
this looks to me like an M4 issue, since a faulty Samba configuration should have caused the same 
error under M3 correct?

Comment 8 DJ Houghton 2003-11-14 13:58:20 EST

Not necessarily, the lock file code was changed in M4 to use java.nio classes.

See bug 38399.

Comment 9 Rafael Chaves 2003-11-14 14:24:10 EST

As DJ mentioned, we started using file-locking capabilities on M4.

Unfortunately, there are some setups that (in some cases) do not seem to allow
file locking (at least in the way Java applications are enabled to acquire). We
are investigating those cases (remote file systems on Samba/NFS, LVM-based file
systems).

So, since you are keeping the same server and using the same Eclipse build (M4),
the difference is probably related to the different client OS version or
Samba-related settings (on the client side).

Comment 10 Adrian Newby 2003-11-14 15:21:33 EST

Here are the smb.conf differences.  ">" means removed; "<" means added.  I don't really know how 
to interpret these but others might.  Of course, it doesn't say anything about which default 
behaviors might have changed as well...


diff smb.conf smb.conf.applesaved 

25a26,27
>   client code page = 437
>   coding system = utf8
30,35d31
<    dos charset = 437
<    unix charset = UTF-8-MAC
<    auth methods = guest opendirectory
<    passdb backend = opendirectorysam guest
<    printer admin = @admin, @staff
<    server string = Mac OS X
49,56c45,51
< [printers]
<    comment = All Printers
<    browseable = no
<    printable = yes
<    public = no
<    writable = no
<    create mode = 0700
<    path = /tmp
---
> ;[printers]
> ;   comment = All Printers
> ;   browseable = no
> ;   printable = yes
> ;   public = no
> ;   writable = no
> ;   create mode = 0700

Comment 11 Rafael Chaves 2003-11-14 16:31:08 EST

If the settings related to the problematic mount point are in the file you
mentioned, so the change must be on the samba client behaviour. Adrian, sorry
for asking it but, could you, by any chance, had been running on a previous
release (<M4)in your old setup?

Andre, since the problem does not have anything to do with Eclipse itself, I
believe that opening a PR against Apple's JDK would be a good idea. A simple
test case appears in bug 44487 comment 9.

Comment 12 Adrian Newby 2003-11-16 17:28:53 EST

For sure, I know that 3.0M3 and OS X 10.2 was working properly.

What I don't know with certainty is whether 3.0M4 ever ran properly on 10.2.  (I realize this 
contradicts my original comment.)  Problem is, I'm not now in a position to test that combination.  
If I had to guess, I would guess that 3.0M4/10.2 would work and that the problem was caused by 
the OS X upgrade.  However, that's only a guess.

What I *can* do is test 3.0M4 on a colleague's Mac that came with 10.3 (Panther) out of the box.  
What that will tell us is whether 3.0M4 out of the box has a problem with Panther out of the box.  If 
I can reproduce the problem there, it seems to me that we have a legitimate problem.  No?

If anyone has any other sugestions, I'm happy to try them out.  (For instance, I believe I might be 
able to repeat the lock test - or even run 3.0M4 - with a 1.3.1 JVM)

Comment 13 Adrian Newby 2003-11-16 17:41:32 EST

OK - forget part of that - I just found out that TestLock can't be compiled with a 1.3.1 JVM.  I 
guess Eclipse would also test for JVM version and only use nio classes if 1.4 was available?  So, 
running Eclipse under 1.3.1 would prove nothing. Right?

Comment 14 Adrian Newby 2003-11-16 18:01:31 EST

More information:  

I can run the TestLock test from a Windows client against the same remote Samba share with no 
failure.  So, the remote Samba share can be eliminated as a possible problem.  This Windows 
platform also runs M4 against this remote Samba share with no locking problems, which would 
also seem to eliminate M4.

That leaves either the Apple JVM or the Mac Samba client.

In an attempt to see if the JVM was the culprit, I ran TestLock against a local filesystem file.  On RH 
Linux 9, I got this:

[newbya@dev-fpserver-01 newbya]$ java TestLock ~/myLock
trying to acquire lock once
trying to acquire lock twice

(Look good to me)

On OS X 10.3, I got this:

[anewby@supernova ~/scratch]$ java TestLock /.lock
trying to acquire lock once
Exception in thread "main" java.io.IOException: Bad file descriptor
        at sun.nio.ch.FileChannelImpl.release0(Native Method)
        at sun.nio.ch.FileChannelImpl.implCloseChannel(FileChannelImpl.java:104)
        at java.nio.channels.spi.AbstractInterruptibleChannel.close(AbstractInterruptibleChannel.java:
97)
        at java.io.FileOutputStream.close(FileOutputStream.java:275)
        at TestLock.acquireLock(TestLock.java:9)
        at TestLock.main(TestLock.java:14)

(Not so good)

Does this look like a JVM bug to you?

Comment 15 Rafael Chaves 2003-11-17 10:46:14 EST

So, the summary is: 
- we don't know for sure whether file locking works on a samba-based location on
Mac OS X 10.2;
- file locking works fine with local file systems (as described in the original
description).

This looks like a misconfiguration or limitation on the samba client on Mac OS X
that does not allow file locking. This has happened on other environments as
well (see bug 44735) for NFS-based locations (although it works fine for me with
both NFS and Samba locations).

The workaround (to disable the .metadata lock file) is described on comment 5.

Adrian: above, you ran the test case against "/.lock". This should be the reason
for the error. You must provide a location to which you have R/W acess.

Unless we find something on the contrary, this is a duplicate of bug 44735.

*** This bug has been marked as a duplicate of 44735 ***

Comment 16 Adrian Newby 2003-11-17 17:59:38 EST

I reran the test case (TestLock) on a local filesystem as follows.  Note that I didn't use .lock as a file 
name.  Since the test case fails even when using a filename guaranteed to have r/w access, I'm not 
sure we can conclusively identify Samba as the culprit.


java TestLock ./thisLocation
trying to acquire lock once
Exception in thread "main" java.io.IOException: Bad file descriptor
        at sun.nio.ch.FileChannelImpl.release0(Native Method)
        at sun.nio.ch.FileChannelImpl.implCloseChannel(FileChannelImpl.java:104)
        at java.nio.channels.spi.AbstractInterruptibleChannel.close(AbstractInterruptibleChannel.java:
97)
        at java.io.FileOutputStream.close(FileOutputStream.java:275)
        at TestLock.acquireLock(TestLock.java:9)
        at TestLock.main(TestLock.java:14)

Comment 17 Adrian Newby 2003-12-05 00:26:17 EST

See comment 16 - test case fails even when accessing local filesystem (although the original 
problem disappears from Eclipse).  Not sure what this means apart from the test case probably 
should not fail under these conditions, correct?

Comment 18 Rafael Chaves 2003-12-05 08:39:42 EST

Sorry for not being clear about, but the location you pass to the test case must
be an *existing file* location. Is that what you are doing?

If Eclipse starts fine with a local workspace, your problem running the test
case must be something else. I strongly believe the problem is related to the
use of a Samba-based file location.

Comment 19 Adrian Newby 2003-12-05 18:06:50 EST

The test fails with an existing file location.  In this case, neither NFS nor Samba have any 
involvement.  I tried it with both zero- and non-zero length files.  (See below)

-- First with a zero-length file ....

[anewby@supernova ~/scratch]$ ls -l
total 16
-rw-r--r--  1 anewby  staff  931 16 Nov 14:37 TestLock.class
-rw-r--r--  1 anewby  staff  714 13 Nov 12:20 TestLock.java
-rw-r--r--  1 anewby  staff    0 17 Nov 14:57 thisLocation

[anewby@supernova ~/scratch]$ java TestLock ./thisLocation 
trying to acquire lock once
Exception in thread "main" java.io.IOException: Bad file descriptor
        at sun.nio.ch.FileChannelImpl.release0(Native Method)
        at sun.nio.ch.FileChannelImpl.implCloseChannel(FileChannelImpl.java:104)
        at java.nio.channels.spi.AbstractInterruptibleChannel.close(AbstractInterruptibleChannel.java:
97)
        at java.io.FileOutputStream.close(FileOutputStream.java:275)
        at TestLock.acquireLock(TestLock.java:9)
        at TestLock.main(TestLock.java:14)
[anewby@supernova ~/scratch]$

-- Now with a non-zero length file ...

[anewby@supernova ~/scratch]$ ls > ./thisLocation 
[anewby@supernova ~/scratch]$ ls -l
total 24
-rw-r--r--  1 anewby  staff  931 16 Nov 14:37 TestLock.class
-rw-r--r--  1 anewby  staff  714 13 Nov 12:20 TestLock.java
-rw-r--r--  1 anewby  staff   42  5 Dec 15:02 thisLocation
[anewby@supernova ~/scratch]$ java TestLock ./thisLocation 
trying to acquire lock once
Exception in thread "main" java.io.IOException: Bad file descriptor
        at sun.nio.ch.FileChannelImpl.release0(Native Method)
        at sun.nio.ch.FileChannelImpl.implCloseChannel(FileChannelImpl.java:104)
        at java.nio.channels.spi.AbstractInterruptibleChannel.close(AbstractInterruptibleChannel.java:
97)
        at java.io.FileOutputStream.close(FileOutputStream.java:275)
        at TestLock.acquireLock(TestLock.java:9)
        at TestLock.main(TestLock.java:14)
[anewby@supernova ~/scratch]$

Comment 20 Rafael Chaves 2004-07-07 12:44:19 EDT

Adrian, are you still seeing this?

Comment 21 Rafael Chaves 2004-07-13 14:54:04 EDT

No further information. Marking as duplicate. Please reopen if this still
happens and the workaround (now in bug 55744 comment 7) does not work.

*** This bug has been marked as a duplicate of 44735 ***