You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Eric Hanchrow <of...@blarg.net> on 2004/09/10 01:43:06 UTC
BUG: svn st => svn: Can't open '.svn/tmp/mixed.pl.tmp': No such
file or directory
This is reproducible. First a word about all the systems involved:
The repository is 1.1.x (r10858) on Linux (recent Debian testing).
--fs-type=fsfs, if it matters.
The client is Cygwin's released version of 1.0.6, running on Win2K
with Service Pack 4.
The working copy lives on an old RedHat box running Samba 2.2.7a, and
is accessed, naturally, via SMB. (kernel 2.4.20-30.9smp, if it
matters)
First I'll describe in vague prose what I'm doing; then I'll include
two shell scripts that more-or-less reliably repro the problem.
("more-or-less" because they may require a tiny amount of tweaking to
accommodate the name of the Windows drive that represents the Samba
directory, the name of the repository's server, and other similarly
tiny things).
I've got a repository on the new Linux box, naturally enough. My
working copy is on the old Linux box, but I'm accessing it (* sigh *)
from Cygwin, via SMB.
I've got "auto-props" enabled, so that Perl scripts get svn:eol-style
"native".
I attempt to check in a Perl script whose line endings are
inconsistent. The checkin attempt naturally fails with the "line
endings are inconsistent" message. No problem there. But: at that
point, my working copy is, as Sussman puts it, horked; `svn st' yields
the scary error message in the Subject: line.
Now, as it happens, this bug, _as described above and in the
scripts below_, isn't particularly nasty, since `svn cleanup' puts
everything back into shape again. However, what I'm describing
here isn't exactly what I originally saw; unfortunately I haven't
figured out how to repro that original bug, which is a shame since
it WAS nasty (`svn cleanup' didn't help; I saw something about
`couldn't access `.svn/lock' because "No such file or directory"'
even though that file clearly existed). So I'm hoping that
someone will look at what I've described, find the responsible
bug, and then realize that that very bug could indeed have been
responsible for the nastier behavior that I only vaguely remember.
Anyway, enough blather. Here are the scripts:
I call this "server.sh":
#!/bin/bash
set -e
cd
rm -rfv $HOME/silly-repos
~svn/local/bin/svnadmin create --fs-type=fsfs $HOME/silly-repos
echo '[general]' > $HOME/silly-repos/conf/svnserve.conf
echo 'anon-access = write' >> $HOME/silly-repos/conf/svnserve.conf
# I'm only using a non-standard port because the box on which the
# repository lives is already running another svnserve on the standard
# port. I doubt the port number has anything to do with this bug.
~svn/local/bin/svnserve -r $HOME/silly-repos --foreground --daemon --listen-port=9918
And I call this "client.sh":
#!/bin/bash
port=9918
server=eng01
c=$HOME/.subversion/config
b=$c.bak
if [ -f $b ]; then
echo will not clobber $b ;
exit
fi
mv $c $b
echo [miscellany] > $c
echo enable-auto-props = yes >> $c
echo [auto-props] >> $c
echo '*.pl = svn:eol-style=native' >> $c
# Of course you'll have to change this letter to match whatever
# network drive you've created.
cd e:/ # <---------------------------- EDIT THIS LINE
w=silly-wc
rm -rf $w
svn co svn://$server:$port $w
cd $w
echo -e A line without a CR > mixed.pl
svn add mixed.pl
svn -m "" ci
echo -e I gots a CR\\r >> mixed.pl
svn -m "" ci
svn st
Run `server.sh' on a recent Linux box with a 1.1.x svn. Then by hand
set up a SMB drive to the older linux box, something like this:
$ net use \* \\\\eng01\share
Then whatever letter that drive is, edit the one line in "client.sh"
that says "EDIT THIS LINE" to match.
Then run server.sh on the server, and client.sh on the client; you'll
see the client output
Transmitting file data .svn: Commit failed (details follow):
svn: Inconsistent line-endings in source stream
svn: Can't open '.svn/tmp/mixed.pl.tmp': No such file or directory
That last line is the bug.
Now to demonstrate that the problem is indeed related to SMB, re-edit
the client script by changing the drive letter so that it now points
to a local file system. Kill the server process, re-start it, and
re-run the client script; you'll then see just the "Inconsistent
line-endings" message, but you will not see the last "Can't open"
message.
--
Asking the Iraqi people to assume Saddam's debts
is rather like telling a man who has been shot in the head
that he has to pay for the bullet.
-- James Surowiecki
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: PATCH: warn against old Samba in the FAQ (was BUG: svn st => svn: Can't open '.svn/tmp/mixed.pl.tmp': No such file or directory)
Posted by kf...@collab.net.
Eric Hanchrow <of...@blarg.net> writes:
> So I think all that remains to be done is to patch the FAQ thusly:
Applied in r10881, thanks!
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
PATCH: warn against old Samba in the FAQ (was BUG: svn st => svn:
Can't open '.svn/tmp/mixed.pl.tmp': No such file or directory)
Posted by Eric Hanchrow <of...@blarg.net>.
Short story: the problem is probably due to a bug in an old version of
Samba.
Longer story:
First I eliminated Cygwin as a possible culprit: the problem happened
equally with the native Win32 subversion binaries.
Then I tried the repro scripts on Samba 3.0.6, and the problem did not
recur.
But more importantly (to me, anyway), I was able to reproduce the
nastier problem to which I vaguely alluded (by simply tarring up the
original messed-up working copy, and experimenting with it), and _it_
also doesn't happen with the newer Samba.
So I think all that remains to be done is to patch the FAQ thusly:
Index: project_faq.html
===================================================================
--- project_faq.html (.../trunk/www/project_faq.html) (revision 10869)
+++ project_faq.html (.../branches/1.1.x/www/project_faq.html) (working copy)
@@ -770,6 +770,12 @@
>NFS Howto Server Guide</a> and <b>exports(5)</b> for more information on
how to disable subtree checking.</p>
+<p>We've had at least one report of working copies getting wedged
+after being accessed via SMB; the server in question was running a
+rather old version of Samba (2.2.7a, to be precise). The problem
+didn't recur with a newer Samba (3.0.6).
+</p>
+
<![CDATA[=========================================================]]>
<h3><a name="bdblogs">Why is my repository taking up so much disk space?</h3>
--
That is the true genius of America ... that our votes will be
counted, at least most of the time.
-- Barack Obama, 2004 Democratic National Convention
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org