Plugin installation fails if default path is inaccessible

[PixelHir]

Not sure if I have some unusual home directory permissions but IINACT was unable to create an IINACT folder in my documents folder.
I created it manually and it worked however it feels a bit unusual for plugin to instantly fail like that - especially if a user could wish to instantly change their IINACT directory on start. Maybe it would be better if user could be still able to install plugin even if IINACT can't access the folder - and inform them appropriately to grant permission or change destination folder?

[marzent]

This is unfortunately not really feasible, since the FFXIV_ACT_Plugin needs to be initialized together with IINACT and at the point in time it is not possible to show a popup or folder selection dialog (at least not without rewriting basically the entire plugin startup sequence)...
But I am wondering, are you running some kind of AV that blocks certain actions in the Documents folder? If so an exclusion for Dalamud and all its plugins would probably also work here.

[PixelHir]

I only have the installed by default windows defender - I have completely no idea why the access was denied as I remember it used to work, maybe that’s some new 24H2 quirk…

[PixelHir]

Oh never mind, it’s not about the permission, I copied plugin configs from my old windows install and the user folder has changed - so that one doesn’t exist. My bad, needed to take a look at the log one more time. Although I have created the new folder in new user folder and it worked after that so I’m not sure if some fallback triggered or something…

[Koenari]

Happened to me just now. Underlying problem seems to be that DefaultLogFIlePath is written to the config file.
This field is missing a [JsonIgnore] and therefore it is possibly defaulting to the wrong user folder.

IINACT/IINACT/Configuration.cs

Line 10 in 933c3d9

public string DefaultLogFilePath = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments), "IINACT");

[marzent]

Indeed you are right, thanks for the catch @Koenari

[marzent]

Part of this issue is fixed in 2.7.3.5 now, I'll still leave this one open though as that scenario could still be handled a bit more gracefully...