08bb69c048
### Problem description
At least on Windows (I have tested), it fails to save a layout on the
non-portable version of ImHex (unless we have an administrator
privilege).
The log (after an attempt to save a layout as "sample") will look like:
| Component | Message |
| --------- | ------- |
| `libimhex` | `Failed to save layout 'sample'. No writable path found`
|
But the underlying problem is platform-agnostic. It can be also a
problem on other platforms in other ways.
### Implementation description
The layout manager incorrectly queried whether the empty path
(effectively the current working directory) is writable before saving
the layout (not each "layouts" directories it queried earlier).
This is the snippet of the root cause.
```cxx
std::fs::path layoutPath;
for (const auto &path : hex::fs::getDefaultPaths(fs::ImHexPath::Layouts)) {
if (!hex::fs::isPathWritable(layoutPath))
continue;
layoutPath = path / fileName;
}
```
Look at the argument we are passing to `isPathWritable`. `layoutPath` is
a default (empty) `std::fs::path` object and will not be updated until
the directory describing itself is confirmed to be writable.
That caused a problem on non-portable version of Windows because:
1. The current working directory is usually the one of the executable
(`imhex-gui.exe`) and
2. That directory (`C:\Program Files\ImHex` by default) is usually not
writable unless ImHex is executed with an Administrator privilege.
The argument to `isPathWritable` should be `path` (containing one of the
`layouts` directories) and this PR fixes so that.
### Screenshots
### Additional things
This issue is hard to notice when developing because, to reproduce this
bug, the current working directory MUST NOT BE writable (usually
writable when we develop, even when we are working on the non-portable
Windows builds).
|
||
|---|---|---|
| .. | ||
| external | ||
| libimhex | ||
| third_party | ||