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

Re: illegal filename under windows

From: Pflästerer, Karl <Karl.Pflaesterer_at_dfv.de>
Date: Sat, 2 Aug 2014 15:03:28 +0000

Am 02.08.14 14:52 schrieb <nkadel_at_gmail.com>:

>On Fri, Aug 1, 2014 at 3:05 AM, Pflästerer, Karl
><Karl.Pflaesterer_at_dfv.de> wrote:
>> Hi,
>> I created a file with the name http<->https.conf and committed it under
>> MacOS. No prolem at all.
>> I could checkout the file on out Linux servers.
>*WHY* do you insist on doing something guaranteed to be incompatible
>across operating systems? Punctuation in file names is anathema to
>good programming practices. characters like '>', '!', '()", '[]",
>quotation marks, spaces, etc. are all known to cause problems for
>locally written pre-commit and post-commit scripts and should be
>avoided as a matter of course.

I tried the filename under MacOS and Linux; no problem. At that moment I
didn’t think of Windows. The filename was just simply explaining what the
file was for: some mod_rewrite rules for jumping between a SSL and non SSL
http process.

>> But most of my colleagues use Windows. As they tried to update their
>> working copies everything stopped.
>They, or you, need to send a command to the upstream repository to
>delete or remove the file there, not to manipulate it inside the local
>working copy. But yes, the potential for screwing up local working
>environments of various kinds is why you

Deleting the file was easy. That was not the problem. The problem was as
I described the state of the WC. They could neither go one version back no

>> Because <> are not allowed under Windows in filenames svn could not
>> the file. But they also couldn’t cleanup the WC.
>> The working copy was completely broken (für svn) and they had to
>> everything new.
>If you're willing to test, you might try what I just suggested. See if
>you can switch back to a tag or revision without the forbidden
>filename in it, as well.

We tested some variants (even a sqlite db from a fresh checkout).

>> IMHO this is a bug. At least svn under Windows should have refused to
>> checkout that file.
>That's a reasonable point. Would it have been possible for them to to
>checkout their working copy to an earlier branch, tag, or revision
>that did not contain the file? Would you be able to test that?

Yes we tested it. As I wrote. They could not go back, because they had to
cleanup first. But they couldn’t cleanup because cleanup couldn’t finish
the transaction.
If I would have known the sqlite db og subverison better I would have
tried to correct in the db.

>> Furthermore: the cleanup command didn’t work because svn could not a
>> with that name. I would have expected cleanup to revert a transaction
>> to complete it.
>Workarounds for system limitations can lead to a lot of complexity in
>upstream code can be extraordinarily destabilizing. Patches like that
>would have to be done very carefully, and could require extensive
>maintenance. Not saying it's not reasonable, but an error in such a
>patch could break other working code in other operating systems.

I understand that but what would habe happened if I had committed such a
file to a public repository? That’s kind of remote DOS attack for windows

Received on 2014-08-02 17:04:04 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.