Fork crashes when encountering "invalid" character when opening repo in WSL

[juljaeg]

Hi,

I have a large repository. When I open that repo in fork in WSL it crashes. When I open the same repository on Windows itself I get an error regarding files in the repository containing invalid characters which are not supported in file/directory names on windows - which is right. In Linux those characters are allowed tho. Is it possible to skip or validate the paths differently when the repository is in WSL?

I know there is some WSL stuff going on but did not want to spam the thread there. Working with the same repo in WSL over e.g. VS Code with WSL remote or plain git cli works fine.

Stacktrace from event viewer (when crashing when in WSL):

Exception information: System.ArgumentException
   at System.IO.Path.CheckInvalidPathChars(System.String, Boolean)
   at System.IO.Path.GetExtension(System.String)
   at Fork.UI.UserControls.FileListUserControl.ApplyAddedEntries(Fork.UI.FileListMode, Fork.Git.ChangedFile[])
   at Fork.UI.UserControls.FileListUserControl.SetItemSource(Fork.Git.ChangedFile[], Boolean, Boolean)
   at Fork.UI.UserControls.StageFileUserControl.SetData(Fork.Git.ChangedFile[], Fork.Git.ChangedFile[])
   at Fork.UI.UserControls.CommitUserControl.RepositoryStatusUpdated(System.Object, Fork.UI.EventArgs`1<Fork.UI.UserControls.RepositoryUserControl>)
   at System.Windows.WeakEventManager+ListenerList`1[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].DeliverEvent(System.Object, System.EventArgs, System.Type)
   at System.Windows.WeakEventManager.DeliverEvent(System.Object, System.EventArgs)
   at Fork.UI.UserControls.RepositoryUserControl.UpdateRepositoryStatus(Fork.Git.RepositoryStatus)
   at Fork.UI.Commands.RefreshRepositoryCommand+<>c__DisplayClass4_0.<RefreshRepositoryStatus>b__0()
   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate, System.Object, Int32)
   at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(System.Object, System.Delegate, System.Object, Int32, System.Delegate)
   at System.Windows.Threading.DispatcherOperation.InvokeImpl()
   at MS.Internal.CulturePreservingExecutionContext.CallbackWrapper(System.Object)
   at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
   at MS.Internal.CulturePreservingExecutionContext.Run(MS.Internal.CulturePreservingExecutionContext, System.Threading.ContextCallback, System.Object)
   at System.Windows.Threading.DispatcherOperation.Invoke()
   at System.Windows.Threading.Dispatcher.ProcessQueue()
   at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef)
   at MS.Win32.HwndWrapper.WndProc(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef)
   at MS.Win32.HwndSubclass.DispatcherCallbackOperation(System.Object)
   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate, System.Object, Int32)
   at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(System.Object, System.Delegate, System.Object, Int32, System.Delegate)
   at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(System.Windows.Threading.DispatcherPriority, System.TimeSpan, System.Delegate, System.Object, Int32)
   at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr, Int32, IntPtr, IntPtr)
   at MS.Win32.UnsafeNativeMethods.DispatchMessage(System.Windows.Interop.MSG ByRef)
   at System.Windows.Threading.Dispatcher.PushFrameImpl(System.Windows.Threading.DispatcherFrame)
   at System.Windows.Application.RunDispatcher(System.Object)
   at System.Windows.Application.RunInternal(System.Windows.Window)
   at Fork.App.Main()

Exception information: System.Reflection.TargetInvocationException
   at System.RuntimeMethodHandle.InvokeMethod(System.Object, System.Object[], System.Signature, Boolean)
   at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(System.Object, System.Object[], System.Object[])
   at System.Reflection.RuntimeMethodInfo.Invoke(System.Object, System.Reflection.BindingFlags, System.Reflection.Binder, System.Object[], System.Globalization.CultureInfo)
   at <Module>.Main(System.String[])

[DanPristupov]

https://github.com/fork-dev/TrackerWin/issues/1539 https://github.com/fork-dev/TrackerWin/issues/1357 https://github.com/fork-dev/TrackerWin/issues/1341

[juljaeg]

Is there an ETA for this since the first reports are ~2 years old? Will this be covered with WSL Support? Especially in large repositories Fork would be helpful now 😕

[DanPristupov]

This is a problem in .Net framework, not in Fork.

Is there an ETA for this since the first reports are ~2 years old?

No

[juljaeg]

I am not sure if this is completly on the framework, as it is made to run in Windows and also acts like it. Admittedly Fork is as well build for Windows and not for WSL Hybrid shenanigans 😥 So I can understand when you say it is an unsupported scenario.

There are ways to address this I think tho. Tho they are either "hacky" (if path starts with something wsl then skip xy - not sure if that even works) or rather ridiculously complex (switching to .NET Core and using the remote backend approach from e.g. VS Code and JetBrains IDEs). Not sure if you got anything like that planned anyway.

So I guess we can close this issue as won't fix or should it stay open?