When a file is opened with a wrong case, it can work on the developer system but break on a user system with a case-sensitive filesystem.
This will display a warning when it happens.
CAVEATS: It will also display the warning if a symlink is in the path.
Adapt warning if the file is a symlink. Avoid warning on symlinks.
Fix memory leak and avoid `lstat` usage.
Avoid exposing real_path when not in TOOLS_ENABLED mode.
When the "filesystem/on_save/safe_save_on_backup_then_rename" option is
enabled files are created with 0666 permissions (-rw-rw-rw-) which is
too loose. Use 0644 (-rw-r--r--) instead which is how the files would
normally be created with the setting disabled and the system umask taken
into account.
`GDExtension::open_library` has a check in it to see if the library was loaded
from a temp file, and if it was to restore the original name as that is the one
we actually care about. This check is breaking extension reloading on Mac when
the library path is to a framework folder, as the file inside the framework
will not generally be the same name as the folder.
This check also shouldn't be necessary even on Windows, which is the only
platform that uses `generate_temp_files`, since disposal of the created temp
file is handled within `OS_Windows::open_dynamic_library`, and
`GDExtension::open_library` (which is the only function to call
`open_dynamic_library` with a `p_data` argument) only cares about the original
library file path and has to do extra work to remove the name of the temp file.
Instead, I have removed that check and set `OS_Windows::open_dynamic_library`
to return the name of the original file and not the name of the copy.
This fixes GDExtension reloading on macOS. I do not have a Windows machine
available to test that it still works properly on Windows, so someone should
check that before merging this.
As many open source projects have started doing it, we're removing the
current year from the copyright notice, so that we don't need to bump
it every year.
It seems like only the first year of publication is technically
relevant for copyright notices, and even that seems to be something
that many companies stopped listing altogether (in a version controlled
codebase, the commits are a much better source of date of publication
than a hardcoded copyright statement).
We also now list Godot Engine contributors first as we're collectively
the current maintainers of the project, and we clarify that the
"exclusive" copyright of the co-founders covers the timespan before
opensourcing (their further contributions are included as part of Godot
Engine contributors).
Also fixed "cf." Frenchism - it's meant as "refer to / see".
- `LIBC_FILEIO_ENABLED` wasn't defined anywhere, even in _other platforms_.
- `NO_NETWORK` is also never defined. It probably isn't enough anyway to
disable network APIs in the current codebase.
- `UNIX_SOCKET_UNAVAILABLE` is never defined in this code but used by some
other platforms, clarify that.
- `NO_STATVFS` can be removed as Android supports it since API level 19,
which is our current min SDK level. It's also only used for
`DirAccessUnix::get_space_left()` which is anyway overridden by
`DirAccessJAndroid::get_space_left()` so it shouldn't make a difference.
* Fixed documentation for `DirAccess.get_space_left()`.
- `NO_FCNTL` is likely also a remnant of early Android days, in current NDK
r23 it seems to be available. Also cleaned up unused `fcntl.h` includes.
- `NO_ALLOCA` is never defined, and we use alloca in many places now.
This was done by refactoring directory and file access handling for the Android platform so that any general filesystem access type go through the Android layer.
This allows us to validate whether the access is unrestricted, or whether it falls under scoped storage and thus act appropriately.
This error message was often displayed for no good reason when PCK
files were loaded in the editor.
Since file modification dates are secondary metadata, it's not
very important if it can't be retrieved successfully anyway.
* Most resource types now have unique identifiers.
* Applies to text, binary and imported resources.
* File formats reference both by text and UID (when available). UID always has priority.
* Resource UIDs are 64 bits for better compatibility with the engine.
* Can be represented and used textually, example `uuid://dapwmgsmnl28u`.
* A special binary cache file is used and exported, containing the mappings.
Example of how it looks:
```GDScript
[gd_scene load_steps=2 format=3 uid="uid://dw86wq31afig2"]
[ext_resource type="PackedScene" uid="uid://bt36ojelx8q6c" path="res://subscene.scn" id="1_t56hs"]
```
GDScript, shaders and other special resource files can't currently provide UIDs, but this should be doable with special keywords on the files.
This will be reserved for future PRs.
The error check was added for `FileAccessUnix` but it's not an error when both
`p_src` and `p_length` are zero.
Added correct error checks to all implementations to prevent the actual
erroneous case: `p_src` is nullptr but `p_length > 0` (risk of null pointer
indexing).
Fixes#33564.
This changes the types of a big number of variables.
General rules:
- Using `uint64_t` in general. We also considered `int64_t` but eventually
settled on keeping it unsigned, which is also closer to what one would expect
with `size_t`/`off_t`.
- We only keep `int64_t` for `seek_end` (takes a negative offset from the end)
and for the `Variant` bindings, since `Variant::INT` is `int64_t`. This means
we only need to guard against passing negative values in `core_bind.cpp`.
- Using `uint32_t` integers for concepts not needing such a huge range, like
pages, blocks, etc.
In addition:
- Improve usage of integer types in some related places; namely, `DirAccess`,
core binds.
Note:
- On Windows, `_ftelli64` reports invalid values when using 32-bit MinGW with
version < 8.0. This was an upstream bug fixed in 8.0. It breaks support for
big files on 32-bit Windows builds made with that toolchain. We might add a
workaround.
Fixes#44363.
Fixesgodotengine/godot-proposals#400.
Co-authored-by: Rémi Verschelde <rverschelde@gmail.com>
Happy new year to the wonderful Godot community!
2020 has been a tough year for most of us personally, but a good year for
Godot development nonetheless with a huge amount of work done towards Godot
4.0 and great improvements backported to the long-lived 3.2 branch.
We've had close to 400 contributors to engine code this year, authoring near
7,000 commit! (And that's only for the `master` branch and for the engine code,
there's a lot more when counting docs, demos and other first-party repos.)
Here's to a great year 2021 for all Godot users 🎆
