On 14.08.2015 00:20, Branko Čibej wrote:
On 13.08.2015 13:32, Marc Strapetz wrote:
On 27.07.2015 09:21, Branko Čibej wrote:
On 27.07.2015 09:17, Marc Strapetz wrote:
One of our 1.9 (early-access) users is reporting problems when
performing remote commands, for example a copy URL->URL:
org.apache.subversion.javahl.ClientException: Stream doesn't support
this capability
Bad file descriptor
svn: Polling for available data on filestream failed: Bad file
descriptor
at org.apache.subversion.javahl.SVNClient.copy(Native Method)
at ...
He hasn't encountered such problems with 1.8 versions.
AFAIU, he is connecting using SSH. Is this an SSH-related problem?
Could it be related to the underlying SSH client?
Which platform is this? Can the user reproduce this problem with the
command-line svn on the same machine?
It's on Windows, in combination with SSH. I'm now able to reproduce
this problem myself and it looks like a regression to me:
It's reproducible with our own Windows binaries as well as with the
WANdisco binaries. It's reproducible with Plink/Pageant as well as
with Trilead SSH. The commit works fine with Subversion 1.8.
Is there any additional information/debugging I can do on my side?
I'd still want to know if the command-line client works. If not, a
minimal Java program using JavaHL that demonstrates the problem would be
a real help.
No, the command-line client does not work: neither the binaries we are
building nor WANdisco's binaries.
It's reproducible with an empty repository on the server (just
initialized with svnadmin) and a local repository which has been
prepared for the initial import:
C:\temp\svn> svn status -v
0 0 ? .
A - ? ? dir
A - ? ? dir\subfile
A - ? ? file
C:\temp\svn> svn commit -m "initial import"
svn: E140004: Commit failed (details follow):
svn: E140004: Stream doesn't support this capability
svn: E000009: Polling for available data on filestream failed: Bad file
descriptor
On the server, we are running SVN 1.6.17.
-Marc
