Hi Daniel, Thanks for elaborating. I agree this network disconnection issue is a truly minor one. At the same time Nathan mentioned several other occurrences of the same issue. So maybe the sum of all information eventually allows TSVN to get this exception handled for the more common use cases.
Best regards, Matthias Von: Daniel Sahlberg <daniel.l.sahlb...@gmail.com> Gesendet: Donnerstag, 14. Juli 2022 16:48 An: Klaey Matthias LCPF-CH <matthias.kl...@mt.com> Cc: Nathan Hartman <hartman.nat...@gmail.com>; users@subversion.apache.org Betreff: Re: EXTERNAL - line 10866: assertion failed (svn_dirent_is_absolute(local_abspath)) Den ons 13 juli 2022 kl 15:35 skrev Klaey Matthias LCPF-CH <matthias.kl...@mt.com<mailto:matthias.kl...@mt.com>>: Hi Nathan, See my responses further below as [MK 2022-07-13: ]. Not sure whether my email properly has the [In-Reply-To] filled-in to end up in https://lists.apache.org/thread/n5vo9kznz9z2gzwy7kym9nj5rl9fw8mw. As I am forced to use Outlook, and googling doesn't tell me how to achieve [In-Reply-To] in Outlook, I can only hope my response gets there. Best regards, Matthias -----Ursprüngliche Nachricht----- Von: Nathan Hartman <hartman.nat...@gmail.com<mailto:hartman.nat...@gmail.com>> Gesendet: Donnerstag, 7. Juli 2022 16:40 An: Klaey Matthias LCPF-CH <matthias.kl...@mt.com<mailto:matthias.kl...@mt.com>> Cc: users@subversion.apache.org<mailto:users@subversion.apache.org> Betreff: Re: EXTERNAL - line 10866: assertion failed (svn_dirent_is_absolute(local_abspath)) On Wed, Jul 6, 2022 at 10:56 AM Klaey Matthias LCPF-CH <matthias.kl...@mt.com<mailto:matthias.kl...@mt.com>> wrote: > I encounter the same exception as > https://lists.apache.org/thread/cxtl57o416ctbbzb315yh6x11kqyn7k3, though > likely with a different cause. In my case: (snip) > 'D:\Development\SVN\Releases\TortoiseSVN-1.14.3\ext\subversion\subversion\libsvn_wc\wc_db.c' > > line 10866: assertion failed (svn_dirent_is_absolute(local_abspath)) We've seen various reports of this exact error on that exact line over the years and it would be nice to finally track down the cause(s). (One thing that could help is to make SVN report the path in question together with the error.) [MK 2022-07-13: In my case, the path is "\\<SomeServer>\<SomeRoot>\<SomeFolderHierarchy>\<MyProject>\Content<file://%3cSomeServer%3e/%3cSomeRoot%3e/%3cSomeFolderHierarchy%3e/%3cMyProject%3e/Content>".] > Environment: > > Windows 10 Enterprise 20H2 19042.1706 > TortoiseSVN 1.14.3, Build 29387 - 64 Bit , 2022/04/08 19:31:22 SVN > repo on some enterprise server SVN working copy on a network drive (I > know this may sound strange but it’s where the issue happens) > > > > Repro steps: > > [TortoiseSVN > Commit] on a large folder of the working copy, i.e. the > operation takes several minutes. > Undock of the laptop where the operation is taking place, i.e. the connection > to the network drive temporarily gets lost è exception. Not sure if I understand correctly, but is the laptop being undocked while the commit is in progress? If so, I wouldn't expect anything to work correctly due to the disconnection. If it's being undocked after the commit is complete, what (if any) other steps do you take that lead to the error? [MK 2022-07-13: Yes, the laptop accidentally being undocked while the commit is in progress. However, as there also is WLAN, the network is only interrupted for the short moment to switch from LAN to WLAN. The exception happens when undocking, i.e. when loosing LAN connection. I understand this is not a typical use case, still I expect TSVN to handle such situation and issue a proper error message, rather than crashing.] If I'm reading the code correctly, the path variable is for some reason incorrect (it is not "absolute", with absolute is defined as starting with \\ or X:\ (X being a drive letter A-Z), with the \ translated to / internally in TSVN). I'm guessing that it is empty, since it doesn't make sense that undocking would just make it loose the \\ or drive letter. I'm not sure if this path is being supplied directly from TSVN or if it is constructed within Subversion code, and I'm not sure if some code could be added to check for an empty path when the network connection is lost. However fast the network is reconnected there will always be a moment with no network. The part of the code that assert is the part that is reading the WC database on the network drive. In this case we are not even communicating with Subversion code on the other end but we are relying on Windows to provide us with access to the SQLite database file. So even if the code would not assert, you might end up with a situation where Windows is telling SQLite "sorry but that file is not available" (which in turn is telling Subversion something similar). Conceivably there could be a "retry" logic that wait for a little while and retry every operation that could be interrupted but I think that will be a significant amount of work, and I'm not sure that will even be considered desirable. All above being said, please also be aware of what TSVN and SQLite say about storing WCs on network shares: * https://tortoisesvn.net/faq.html#wconshare * https://www.sqlite.org/faq.html#q5 Kind regards, Daniel Sahlberg
