[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: check-mime-type, Windows client, non-ASCII path

From: Nico Kadel-Garcia <nkadel_at_gmail.com>
Date: Wed, 1 Feb 2012 07:17:45 -0500

2012/2/1 Ignacio González (Eliop) <igtorque.eliop_at_googlemail.com>:
> Clients: Windows-XP, Windows 7, svn 1.6.16 (Spanish)
> Server: Linux (CentOS), svn 1.6.16 (Spanish)
>
> Repository created OK
> Hundreds of revisions already checked-in OK
> Hook "check-mime-type" (bash) added in server
> A couple of revisions checked-in OK
> New file added with non-ASCII characters -> Problem:
> Path name (in Windows, client): C:\Usuarios\arenero\Inútil.TXT
> (note the u with an acute accent: ú)
>
> C:\Usuarios\arenero>svn ci acentos -m "Prueba 1"
> Adding         acentos
> Adding         acentos\In£til.TXT
> Transmitting file data .svn: Commit failed (details follow):
> svn: Commit blocked by pre-commit hook (exit code 1) with output:
> /opt/csvn/data/repositories/telecontrol/hooks/check-mime-type:
> `/opt/csvn/bin/sv
> nlook proplist /opt/csvn/data/repositories/arenero -t 44-1e --verbose
> acentos/In
> ?\195?\186til.TXT' failed with this output:
> svnlook: Path 'acentos/In?\195?\186til.TXT' does not exist
>
> To help diagnose it, I tried to check out an already existing file with
> accents in its name
> (checked in before the Hook "check-mime-type" (bash) was added in the
> server).
> Check out fails.
> Oh, my God.
>
> Suggestions ?

First, avoid non-ascii characters in file names. It causes real
problems with pre-commit hooks and post-commit hooks that do not
properly quote their arguments, and that's not something you can
handle on the client side. And I've had network file shares used for
working copies, such as NetApp serviced home directories NFS mounted
as /home/$USER on the Linux side and CIFS mounted $HOMEDIR on the
Windows side, where people generated files on the Windows side,
successfully checked them in, and couldn't successfully read or delete
the files on the Linux NFS side because the server hadn't been set up
with UTF compatible NetApp filesystems.

Second, can you check out the *directory* that ocntains the file by
using the directory name, and letting the client deal with the
wackiness? And can you use 'svn mv', or do your operations with a
TortoiseSVN client, which is really handy for getting files with funny
names correctly processed?
Received on 2012-02-01 13:18:16 CET

This is an archived mail posted to the Subversion Users mailing list.