Error when extracting files with too long filenames (and a minor UI issue)

[Aclios]

Describe the bug

UABEA is (logically) failing to write files with very long filenames (>255), since it is above the maximum path length limitation.
Also a UI minor issue (maybe intended though) : UABEA only shows the first 100 characters of the filenames. At least adding a "..." at the end to notify the user the filename has been cut could be a good idea, imho.

Error log:

System.IO.IOException: La syntaxe du nom de fichier, de répertoire ou de volume est incorrecte. : 'C:\error\TimeMachineClip(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)(Clone)-resources.assets-13246.txt'
at Microsoft.Win32.SafeHandles.SafeFileHandle.CreateFile(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options)
at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize)
at System.IO.Strategies.OSFileStreamStrategy..ctor(String path, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize)
at UABEAvalonia.InfoWindow.BatchExportDump(List`1 selection) in D:\a\UABEA\UABEA\UABEAvalonia\Forms\InfoWindow.axaml.cs:line 0
at UABEAvalonia.InfoWindow.BtnExportDump_Click(Object sender, RoutedEventArgs e) in D:\a\UABEA\UABEA\UABEAvalonia\Forms\InfoWindow.axaml.cs:line 329
at System.Threading.Tasks.Task.<>c.b__128_0(Object state)
at Avalonia.Threading.SendOrPostCallbackDispatcherOperation.InvokeCore()
at Avalonia.Threading.DispatcherOperation.Execute()
at Avalonia.Threading.Dispatcher.ExecuteJob(DispatcherOperation job)
at Avalonia.Threading.Dispatcher.ExecuteJobsCore(Boolean fromExplicitBackgroundProcessingCallback)
at Avalonia.Threading.Dispatcher.Signaled()
at Avalonia.Win32.Win32Platform.WndProc(IntPtr hWnd, UInt32 msg, IntPtr wParam, IntPtr lParam)
at Avalonia.Win32.Interop.UnmanagedMethods.DispatchMessage(MSG& lpmsg)
at Avalonia.Win32.Win32DispatcherImpl.RunLoop(CancellationToken cancellationToken)
at Avalonia.Threading.DispatcherFrame.Run(IControlledDispatcherImpl impl)
at Avalonia.Threading.Dispatcher.PushFrame(DispatcherFrame frame)
at Avalonia.Threading.Dispatcher.MainLoop(CancellationToken cancellationToken)
at Avalonia.Controls.ApplicationLifetimes.ClassicDesktopStyleApplicationLifetime.Start(String[] args)
at Avalonia.ClassicDesktopStyleApplicationLifetimeExtensions.StartWithClassicDesktopLifetime(AppBuilder builder, String[] args, ShutdownMode shutdownMode)
at UABEAvalonia.Program.Main(String[] args) in D:\a\UABEA\UABEA\UABEAvalonia\Program.cs:line 53

To Reproduce

Try to batch dump export files from a .assets file, with one of the filenames being too big.
I got this error with the game Little Goody Two Shoes, with the asset file is resources.assets

Expected behavior

I guess there is no ideal solution for this case, maybe the best thing to do is to skip those files and notify the user, so at least a full dump can be achieved for the other files.

Maybe tell people it would work if they increase their MAX_PATH, but it's not really user friendly.

[nesrak1]

UABEA is (logically) failing to write files with very long filenames (>255), since it is above the maximum path length limitation.

That should be easy enough. Batch import won't use the display portion (everything before -resources.assets), so I can chop the end off of the display part until it's below 255. If the other filename pushes it too long (for example, if resources.assets was instead resources.assetsaaaaaaaaa... near the file name limit), I might have to fail and skip it.

At least adding a "..." at the end to notify the user the filename has been cut could be a good idea, imho.

Sounds like a good idea. I'll do that.