Crash of SlikSVN 1.8.9 under Windows 7 / 64-bit
Hi all, during usage of the above version of SlikSVN I got the following console output: This application has halted due to an unexpected error. A crash report and minidump file were saved to disk, you can find them here: C:\Users\wepuser\AppData\Local\Temp\svn-crash-log20140801125220.log C:\Users\wepuser\AppData\Local\Temp\svn-crash-log20140801125220.dmp Please send the log file to users@subversion.apache.org to help us analyze and solve this problem. Please find the respective file enclosed. Best regards Ulrich Post Software AG – Sitz/Registered office: Uhlandstraße 12, 64297 Darmstadt, Germany – Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), Dr. Wolfram Jost, Arnd Zinnhardt; - Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com svn-crash-log20140801130700.log Description: svn-crash-log20140801130700.log
Re: Crash of SlikSVN 1.8.9 under Windows 7 / 64-bit
Hi, > On 1 Aug 2014, at 12:15, "Post, Dr. Ulrich" > wrote: > > Please find the respective file enclosed. This file contains a username and a password which you may want to reset as soon as practical if required. Andreas
Re: illegal filename under windows
On Fri, Aug 1, 2014 at 3:05 AM, Pflästerer, Karl 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. > 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 Do-Not-Put-Punctuation-In-File-Names.txt. > Because <> are not allowed under Windows in filenames svn could not create > the file. But they also couldn’t cleanup the WC. > The working copy was completely broken (für svn) and they had to checkout > 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. > 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? > Furthermore: the cleanup command didn’t work because svn could not a file > with that name. I would have expected cleanup to revert a transaction not > 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.
Re: illegal filename under windows
On Sat, Aug 02, 2014 at 08:52:19AM -0400, Nico Kadel-Garcia wrote: > On Fri, Aug 1, 2014 at 3:05 AM, Pflästerer, Karl > wrote: > > Furthermore: the cleanup command didn’t work because svn could not a file > > with that name. I would have expected cleanup to revert a transaction not > > 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. There is a misconception in Karl's question. 'svn cleanup' doesn't deal with transactions. It merely removes working copy locks to make operating on the working copy possible after a buggy or terminally killed client left stale locks. The working copy isn't transactional beyond the transactions sqlite provides and those cannot be rolled back once applied. An update that hasn't finished properly leaves 'incomplete' nodes which must be completed by another update. If a node can't be completed the working copy is in a wedged state. I suppose this is what happened here. >From the design perspective, I suppose we could handle this case with the same approach used for 'server-excluded' and 'not-present' nodes. Subversion's working copy has a concept of 'server-excluded' nodes, i.e. nodes which are technically part of the working copy but were excluded e.g. due to authorization restrictions. If you aren't allowed to see a node in the repository, it won't show up in the working copy, except for a 'server-excluded' node in meta data that reveals the hidden node's name but nothing else. This allows the client to ask for updates to that node in case authorization rules change. 'not-present' nodes are used with mixed-revision working copies where the children of a directory are at a revision in which they don't exist, but their parent directory is at a revision where they do exist. Consider a single-revision working copy at revision 2, where we run: svn rm epsilon/zeta svn commit # committed revision 3 'epsilon' itself remains at revision 2 (if you don't understand why, see http://svnbook.red-bean.com/en/1.7/svn.basic.in-action.html#svn.basic.in-action.mixedrevs ) But epsilon/zeta is at a revision where it was deleted. This is modeled by inserting a 'not-present' node for epsilon/zeta in the nodes table. sqlite> select local_relpath, revision, presence from nodes where local_relpath like '%epsilon%'; local_relpath revisionpresence - -- -- epsilon2 normal epsilon/zeta 3 not-present Perhaps filenames which cannot be represented could be dealt with in a similar way. The node would not show up, and would be 'not-supported' instead of 'incomplete' (note that 'incomplete' is another possible value of the presence column, indicating a node which still needs to be updated). This would certainly have ramifications for existing behaviour and is not a trivial change to make. But I think the idea is worth exploring for someone who has the time and energy for doing so. Perhaps Karl is interested in a side project involving C and sqlite to scratch his own itch? ;)
Re: illegal filename under windows
Am 01.08.14 20:49 schrieb : > >On Aug 1, 2014, at 2:05 AM, Pflästerer, Karl wrote: >> >> 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. >> >> But most of my colleagues use Windows. As they tried to update their >> working copies everything stopped. >> >> Because <> are not allowed under Windows in filenames svn could not >>create >> the file. But they also couldn’t cleanup the WC. >> The working copy was completely broken (für svn) and they had to >>checkout >> everything new. >> >> IMHO this is a bug. At least svn under Windows should have refused to >> checkout that file. >> Furthermore: the cleanup command didn’t work because svn could not a >>file >> with that name. I would have expected cleanup to revert a transaction >>not >> to complete it. > >What version of Subversion were your colleagues using on Windows? Was >this TortoiseSVN or some other Subversion binary? > They used TortoiseSVN; it’s the most recent version. We also tried repair the broken Wc with the cli from Tortoise. We had no luck
Re: illegal filename under windows
Am 02.08.14 14:52 schrieb : >On Fri, Aug 1, 2014 at 3:05 AM, Pflästerer, Karl > 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 >Do-Not-Put-Punctuation-In-File-Names.txt. 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 forward. > >> Because <> are not allowed under Windows in filenames svn could not >>create >> the file. But they also couldn’t cleanup the WC. >> The working copy was completely broken (für svn) and they had to >>checkout >> 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 >>file >> with that name. I would have expected cleanup to revert a transaction >>not >> 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 user. KP
Re: illegal filename under windows
On Sat, Aug 2, 2014 at 9:35 AM, Stefan Sperling wrote: > 'epsilon' itself remains at revision 2 (if you don't understand why, see > http://svnbook.red-bean.com/en/1.7/svn.basic.in-action.html#svn.basic.in-action.mixedrevs > ) > But epsilon/zeta is at a revision where it was deleted. This is modeled > by inserting a 'not-present' node for epsilon/zeta in the nodes table. > > sqlite> select local_relpath, revision, presence from nodes where > local_relpath like '%epsilon%'; > local_relpath revisionpresence > - -- -- > epsilon2 normal > epsilon/zeta 3 not-present > > Perhaps filenames which cannot be represented could be dealt with in a > similar way. The node would not show up, and would be 'not-supported' > instead of 'incomplete' (note that 'incomplete' is another possible > value of the presence column, indicating a node which still needs > to be updated). This would certainly have ramifications for existing > behaviour and is not a trivial change to make. But I think the idea > is worth exploring for someone who has the time and energy for doing so. > Perhaps Karl is interested in a side project involving C and sqlite > to scratch his own itch? ;) That sounds like a feasible technical solution to the general problem. I'm concerned that it will contribute to poor or unstable workflow. It could work locally, until you do the "svn checkout" under a multi-platform shared filesystem, like NFS, and expect to use the same working copy on a more restricted platform, like Windows. I know a stack of Java developers who do this sort of thing, using their personal Mac or Windows environments for their favoriter IDE, and who'd get *really surprised* when their build tools produce different results on a different platform with the same working copy. And just wait until some smart aleck uses it to activate local config files depending on which OS does the checkout and makes the working copy, or to embed stored credentials in ways that their Windows using boss won't see in checkout, but they can see on their MacOS or Linux checkout. Thee is an obligatory xkcd cartoon about this sort of workflow whackiness: http://xkcd.com/1172/ Personally, I'd suggest using a pre-commit for multi-platform environments that says "no OS-incompatible characters in file names! No! Don't do that No cookie for *you*!" I'd also block the use of 'svn:eol' for similar reasons. It's a much simpler, lighter weight approach and less likely to destabilizing working software. In this case in particular, embedding '<>' characteris in a file name is a great way to break any command line scripting that has to deal with the files, and should be avoided in filenames on general principles. Seriously: don't do that. The frase '-to+from-' could be used to substitute, quite legibly.
Re: illegal filename under windows
Am 02.08.14 15:35 schrieb : >On Sat, Aug 02, 2014 at 08:52:19AM -0400, Nico Kadel-Garcia wrote: >> On Fri, Aug 1, 2014 at 3:05 AM, Pflästerer, Karl >> wrote: >> > Furthermore: the cleanup command didn’t work because svn could not a >>file >> > with that name. I would have expected cleanup to revert a transaction >>not >> > 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. > >There is a misconception in Karl's question. 'svn cleanup' doesn't >deal with transactions. It merely removes working copy locks to >make operating on the working copy possible after a buggy or >terminally killed client left stale locks. > >The working copy isn't transactional beyond the transactions sqlite >provides and those cannot be rolled back once applied. An update that >hasn't finished properly leaves 'incomplete' nodes which must be >completed by another update. If a node can't be completed the working >copy is in a wedged state. I suppose this is what happened here. > >From the design perspective, I suppose we could handle this case with >the same approach used for 'server-excluded' and 'not-present' nodes. > >Subversion's working copy has a concept of 'server-excluded' nodes, >i.e. nodes which are technically part of the working copy but were >excluded e.g. due to authorization restrictions. If you aren't allowed >to see a node in the repository, it won't show up in the working copy, >except for a 'server-excluded' node in meta data that reveals the >hidden node's name but nothing else. This allows the client to ask >for updates to that node in case authorization rules change. > >'not-present' nodes are used with mixed-revision working copies >where the children of a directory are at a revision in which they >don't exist, but their parent directory is at a revision where they >do exist. Consider a single-revision working copy at revision 2, >where we run: > svn rm epsilon/zeta > svn commit # committed revision 3 > >'epsilon' itself remains at revision 2 (if you don't understand why, see >http://svnbook.red-bean.com/en/1.7/svn.basic.in-action.html#svn.basic.in-a >ction.mixedrevs ) >But epsilon/zeta is at a revision where it was deleted. This is modeled >by inserting a 'not-present' node for epsilon/zeta in the nodes table. > >sqlite> select local_relpath, revision, presence from nodes where >local_relpath like '%epsilon%'; >local_relpath revisionpresence >- -- -- >epsilon2 normal >epsilon/zeta 3 not-present > >Perhaps filenames which cannot be represented could be dealt with in a >similar way. The node would not show up, and would be 'not-supported' >instead of 'incomplete' (note that 'incomplete' is another possible >value of the presence column, indicating a node which still needs >to be updated). This would certainly have ramifications for existing >behaviour and is not a trivial change to make. But I think the idea >is worth exploring for someone who has the time and energy for doing so. >Perhaps Karl is interested in a side project involving C and sqlite >to scratch his own itch? ;) That sounds really interesting. (I really thought all operations would be in SQL transactions to allow an easy rollback if something goes wrong). But I must say, that at the moment I wouldn’t be a great help. Fortunately at work we have so much to do that I wouldn’t want others waiting for me completing a feature where I couldn’t spend as much time as I liked. Perhaps next year will be a bit more relaxed regarding time. KP
Re: illegal filename under windows
On Sat, Aug 02, 2014 at 11:06:41AM -0400, Nico Kadel-Garcia wrote: > On Sat, Aug 2, 2014 at 9:35 AM, Stefan Sperling wrote: > > > 'epsilon' itself remains at revision 2 (if you don't understand why, see > > http://svnbook.red-bean.com/en/1.7/svn.basic.in-action.html#svn.basic.in-action.mixedrevs > > ) > > But epsilon/zeta is at a revision where it was deleted. This is modeled > > by inserting a 'not-present' node for epsilon/zeta in the nodes table. > > > > sqlite> select local_relpath, revision, presence from nodes where > > local_relpath like '%epsilon%'; > > local_relpath revisionpresence > > - -- -- > > epsilon2 normal > > epsilon/zeta 3 not-present > > > > Perhaps filenames which cannot be represented could be dealt with in a > > similar way. The node would not show up, and would be 'not-supported' > > instead of 'incomplete' (note that 'incomplete' is another possible > > value of the presence column, indicating a node which still needs > > to be updated). This would certainly have ramifications for existing > > behaviour and is not a trivial change to make. But I think the idea > > is worth exploring for someone who has the time and energy for doing so. > > Perhaps Karl is interested in a side project involving C and sqlite > > to scratch his own itch? ;) > > That sounds like a feasible technical solution to the general problem. > > I'm concerned that it will contribute to poor or unstable workflow. That depends on how the client behaves when it encounters the problem. There is no need for the client to silently gloss over the issue. Rather than renderung the working copy inoperational, the node can be recorded, and the client can yell at the user for trying to use a filename that isn't supported by the local OS. But it could do so in a way that allows the user to recover from the situation. The main point of the idea is that the working copy stays operational.
RE: illegal filename under windows
> -Original Message- > From: Pflästerer, Karl [mailto:karl.pflaeste...@dfv.de] > Sent: zaterdag 2 augustus 2014 17:11 > To: Stefan Sperling; Nico Kadel-Garcia > Cc: users@subversion.apache.org > Subject: Re: illegal filename under windows > > Am 02.08.14 15:35 schrieb : > > > >On Sat, Aug 02, 2014 at 08:52:19AM -0400, Nico Kadel-Garcia wrote: > >> On Fri, Aug 1, 2014 at 3:05 AM, Pflästerer, Karl > >> wrote: > >> > Furthermore: the cleanup command didn’t work because svn could not > a > >>file > >> > with that name. I would have expected cleanup to revert a transaction > >>not > >> > 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. > > > >There is a misconception in Karl's question. 'svn cleanup' doesn't > >deal with transactions. It merely removes working copy locks to > >make operating on the working copy possible after a buggy or > >terminally killed client left stale locks. > > > >The working copy isn't transactional beyond the transactions sqlite > >provides and those cannot be rolled back once applied. An update that > >hasn't finished properly leaves 'incomplete' nodes which must be > >completed by another update. If a node can't be completed the working > >copy is in a wedged state. I suppose this is what happened here. > > > >From the design perspective, I suppose we could handle this case with > >the same approach used for 'server-excluded' and 'not-present' nodes. > > > >Subversion's working copy has a concept of 'server-excluded' nodes, > >i.e. nodes which are technically part of the working copy but were > >excluded e.g. due to authorization restrictions. If you aren't allowed > >to see a node in the repository, it won't show up in the working copy, > >except for a 'server-excluded' node in meta data that reveals the > >hidden node's name but nothing else. This allows the client to ask > >for updates to that node in case authorization rules change. > > > >'not-present' nodes are used with mixed-revision working copies > >where the children of a directory are at a revision in which they > >don't exist, but their parent directory is at a revision where they > >do exist. Consider a single-revision working copy at revision 2, > >where we run: > > svn rm epsilon/zeta > > svn commit # committed revision 3 > > > >'epsilon' itself remains at revision 2 (if you don't understand why, see > >http://svnbook.red-bean.com/en/1.7/svn.basic.in- > action.html#svn.basic.in-a > >ction.mixedrevs ) > >But epsilon/zeta is at a revision where it was deleted. This is modeled > >by inserting a 'not-present' node for epsilon/zeta in the nodes table. > > > >sqlite> select local_relpath, revision, presence from nodes where > >local_relpath like '%epsilon%'; > >local_relpath revisionpresence > >- -- -- > >epsilon2 normal > >epsilon/zeta 3 not-present > > > >Perhaps filenames which cannot be represented could be dealt with in a > >similar way. The node would not show up, and would be 'not-supported' > >instead of 'incomplete' (note that 'incomplete' is another possible > >value of the presence column, indicating a node which still needs > >to be updated). This would certainly have ramifications for existing > >behaviour and is not a trivial change to make. But I think the idea > >is worth exploring for someone who has the time and energy for doing so. > >Perhaps Karl is interested in a side project involving C and sqlite > >to scratch his own itch? ;) > > > That sounds really interesting. (I really thought all operations would be > in SQL transactions to allow an easy rollback if something goes wrong). > But I must say, that at the moment I wouldn’t be a great help. Fortunately > at work we have so much to do that I wouldn’t want others waiting for me > completing a feature where I couldn’t spend as much time as I liked. > Perhaps next year will be a bit more relaxed regarding time. The database updates are in SQL transactions... But what we are talking about here are filesystem operations, which our SQL database can't handle via its transactions. Inside the SQL transaction we can store workqueue items: Things like: this file must be YYYed, to complete the operation. YYYed can be something like translated, installed, moved, deleted. etc. But these operations might take a long time and/or might temporary fail, and might be cancelled by the user The working copy is then in a stable state once the workqueue items are completely handled... 'svn cleanup'-s task it to continue doing the remaining work and then mark the working copy stable again. In this case this will work against you... as installing the file
Re: illegal filename under windows
On 02.08.2014 17:06, Nico Kadel-Garcia wrote: > The frase '-to+from-' could be used to substitute, quite legibly. Except that the + is magic for Windows command-line copy. :) -- Brane (It's "phrase" btw, not "frase"). -- Branko Čibej | Director of Subversion WANdisco | Realising the impossibilities of Big Data e. br...@wandisco.com
Re: illegal filename under windows
On 02.08.2014 17:03, Pflästerer, Karl wrote: > > Am 02.08.14 14:52 schrieb : > >> On Fri, Aug 1, 2014 at 3:05 AM, Pflästerer, Karl >> wrote: >>> Hi, >>> >>> I created a file with the name http<->https.conf and committed it under >>> MacOS. No prolem at all. *IF* you happen to quote arguments correctly on the command line and/or shell scripts. In my experience, at least 80% of shell scripts out there are broken in this respect. GUI file managers don't count, they don't pass arguments through the shell, and most filesystems used on these platforms happen not to have these restrictions. Of course, if you mount a CIFS share from Windows onto Linux, you'll end up in the same mess; the character set restrictions are not only a feature of the OS, but also of the filesystem. -- Brane -- Branko Čibej | Director of Subversion WANdisco | Realising the impossibilities of Big Data e. br...@wandisco.com
bug with autoindex on Apache 2.4 when loading SVN modules
I have found that if I have these two configuration statements on my Apache server, I can no longer use auto index. LoadModule dav_svn_module /usr/local/subversion/modules/mod_dav_svn.so LoadModule authz_svn_module /usr/local/subversion/modules/mod_authz_svn.so If I remove those two modules, auto index works perfectly. Has anyone else seen this? Is there a possible work around? I'm using Apache 2.4.10, subversion 1.8.9, Apr 1.5.0, Apr-util 1.5.3, and Serf 1.3.6. I'm not sure if there is any more information I can give you that would be helpful. Information in this e-mail may be confidential. It is intended only for the addressee(s) identified above. If you are not the addressee(s), or an employee or agent of the addressee(s), please note that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this e-mail in error, please notify the sender of the error.
Re: illegal filename under windows
On Sat, Aug 2, 2014 at 3:02 PM, Branko Čibej wrote: > On 02.08.2014 17:06, Nico Kadel-Garcia wrote: > > The frase '-to+from-' could be used to substitute, quite legibly. > > > Except that the + is magic for Windows command-line copy. :) > > -- Brane > > (It's "phrase" btw, not "frase"). Goot points. I'm afraid I saw the "frase" after I sent the message.
