Avoid BLI_path_slash_rfind for accessing file-names as NULL is returned
when the path has no slashes, use BLI_path_basename instead.
Also remove 2 cases where BLI_path_basename was inlined.
This function handles cleaning valid system paths that are functional
when passed to `open(..)` but may be relative to the current working
directory or have redundant slashers that can be normalized.
- Add BLI_path_slash_ensure_ex which takes the string length.
- Normalize functions now return the string length,
so ensuring trailing a trailing slash is a simple check.
This would have avoided the off-by-one error from
761eac2f5d.
Ensure the file path G.main->filepath is always absolute and normalized.
- It was possible to call WM_OT_open_mainfile with only a filename,
if this resolved from the CWD, Blender's internal filepath
would not be absolute as expected.
- It was possible to open files on UNIX with an additional forward slash
causing the blend file path it's self to contain a '//' prefix,
this is error prone as running BLI_path_abs(..) multiple times would
add the blend file prefix each time.
- Remove requirement for "filepath" to be an absolute path when saving.
Instead, expand the path - making it absolute, as this constraint
wasn't applied open opening files, prefer making save/open behave
consistently.
- Assert when BLI_path_abs/BLI_path_rel receive a basepath that has
a "//" (relative) prefix itself.
These are now the only two BLI_path functions which assume paths are
FILE_MAX size which makes sense as they're using the `//` file prefix.
Something that's specific to file paths stored in DNA.
Use FILE_MAX in the function signature as a form of documentation.
- Don't duplicate/allocate the path on each recursion,
instead make a single copy which is modified in-place.
- Move slash-stepping to a BLI_path utility function that accesses
the end position of the parent directory, handles multiple slashes
and '/./'.
- Names ending with len sometimes referred to the buffer size.
The same names were used for both buffer size and string length
depending on the function in some cases.
- Rename str/string to path for generic path functions.
- Rename BLI_path_rel arguments (file, relfile) to (path, basename)
as it wasn't so clear which is being made relative, `file` can be a
directory so rename to `path` (matches naming for BLI_path_abs).
- Avoid inline ifdef checks for DEBUG_STRSIZE
- Add BLI_string_debug_size_after_nil to ensure strings to manipulate
have the expected buffer size after the nil terminator.
- Add checks to more string manipulation functions.
Further changes are required for this to be enabled during regular
development as the RNA currently allocates the strings length but
passes in the buffer size as a limit which conflicts with DEBUG_STRSIZE.
- Rename name/filename/path to filepath when it's used for full paths.
- Rename name/path to dirpath when it refers to a directory.
- Rename file to filepath or path (when it may be a file or dir).
- Rename ImBuf::name & anim::name to filepath.
Rename BLI_make_existing_file to BLI_file_ensure_parent_dir_exists.
The previous name read as if it would make (touch) the file,
where as it ensures the directory component of the path exists.
Move from BLI_path to BLI_fileops as path utilities should only
manipulate paths and not deal with file IO creation
(this has more in common with BLI_file_touch for e.g.).
- Avoid a separate memmove call for each `..`.
- Avoid ambiguous path stepping, where separator literals
needed to be checked to avoid fence post errors.
- Correct & update the doc-string.
Keep these operations separate to simplify path handling logic & docs.
Many callers passed NULL and there were times paths were passed in which
didn't make any sense (where the paths had already been made absolute).
- Don't attempt to skip the WIN32 drive component on relative paths
it's possible this would have unexpected behavior but paths like
are already unlikely to work as expected, e.g. "//C:\".
- Remove early returns for empty paths as there is no need for special
handling.
- Add path normalize NOP tests
Follow Python's os.path.normpath's handing on relative paths in more
situations.
- Leading './' is always stripped.
- Relative paths such as `//./a` & `///a` normalize to `//a`.
- Support for trailing `/..` on the end of paths.
- Avoid empty paths for relative paths that would otherwise
resolve to an empty string, e.g: `a/b/c/../../..` resolves to `.`.
- Calculate spans of redundant `//` & `/./` before calling `memmove`.
- Loop backwards when removing path elements for greater efficiency.
- When removing `/../` components, avoid continuously searching from
the start of the path and instead search from the last found '/../'.
The only WIN32 specific behavior the drive or UNC prefix is skipped
(except for it's slash), allowing WIN32 & Unix paths to share the same
code-path.
Note that this changes behavior for WIN32 when there are too many parent
directories, where ".." that move before the root directory are removed
instead of being left in the path. e.g:
`C:\a\..\..\b` resolved to `C:\..\b` whereas now the result is `C:\b`.
This matches Python's `os.path.normpath`.
Some callers that access the extension operated on the end of the path
even when there was no extension. Using this avoids having to assign
the end of the string using a separate check.
The file extension was copied into a buffer without checking it's size.
While large extensions aren't typical, some callers used small fixed
size buffers so an unusually named file could crash.
While replacing the extension with an empty string works,
it required a redundant string-size argument which took a dummy
value in some cases. Avoid having to pass in a redundant string size by
adding a function that strips the extension.
