---
The blendfile module within BAT supports reading data from structs, such
as the Count property on an array modifier. However, blendfile only
supports modifying structs with type "char". This patch adds support for
writing structs of more types in blendfile blocks. Now, writing is
supported for ushort, short, uint, int, float, and ulong types.
The use case that inspired this patch was an instance where a file had
several array modifiers that prevented the file from being opened in
Blender on machines without large amounts of RAM. A solution using the
blendfile module may look like:
```
from blender_asset_tracer import blendfile
from pathlib import Path
b = blendfile.open_cached(Path('flag.blend'), mode='rb+')
for block in b.blocks:
if 'ArrayModifierData' in block.__str__():
try:
print('previous:', block.get(b'count'))
block.set(b'count', 1)
print('current:', block.get(b'count'))
except KeyError:
continue
b.close()
```
This would fail with the exception
`blender_asset_tracer.blendfile.exceptions.NoWriterImplemented: Setting
type Struct(b'int') is not supported for ArrayModifierData.count`. With
this patch, the above code succeeds and the count struct can be set to
a lower number that allows the file to be opened.
This solution implements missing functionality without adding any new
interfaces. A few details are:
* When deciding what type to write to the struct, the value is inferred
from what is given by the caller. If the caller gives a Python int, the
exact type is inferred from the DNA type ID. If they give a float, a
float is written. Otherwise, the existing logic is used to determine
whether to write a string or byte sequence.
* A \_write method was added to dna\_io.py that takes a Python struct
object and a value to write a byte sequence to the file object. This
method is used by public methods appropriately named to indicate what
type they will write.
* The check for whether the caller is trying to write an unsupported
type is left in place, but it has been changed to include types which
are now supported.
* Tests have been added that provide a mock file object, call the new
methods, and confirm that the correct bytes were written.
Reviewed By: sybren
Differential Revision: https://developer.blender.org/D14374
File permissions are no longer copied when packing. This means that
read-only source files can still be packed without errors, even when
they have to be rewritten (due to changed paths).
Reviewed by: sybren
Differential Revision: https://developer.blender.org/D13128
BAT now can take advantage of the `zstandard` module to handle Blender
3.0+ compressed blend files.
If the module is not installed, the blend files cannot be opened but
GZip-compressed and uncompressed files can still be handled.
Add support for linked collections that are used as input in a Geometry
Nodes modifier. This requires iterating over the geometry nodes modifier
settings, which consists of ID properties. If such an ID property is of
type `IDP_ID`, its pointer is followed and the pointed-to datablock +
its library are visited.
This following of pointers happens in the 'expand' phase, which was only
done for linked library blend files. Since this commit, the old
behaviour of simply looping over all non-`DATA` datablocks of the
to-be-packed blend file is not enough, and datablock expansion is done
for all local datablocks as well.
Add a 'strict pointer mode' to the `BlendFile` class, which is enabled
by default. This allows users of the `BlendFile` class to decide whether
a bad pointer (i.e. one that points to a non-existing datablock) returns
`None` or raises a `SegmentationFault` exception.
This commit fixes a bunch of issues at the same time, as they are all
related to path handling:
- `pathlib.Path.resolve()` or `.absolute()` are replaced by
`bpathlib.make_absolute()`. The latter does NOT follow symlinks and does
NOT network mounts from a drive letter to UNC notation. This also has
advantages on non-Windows sytems, as it allows BAT-packing a directory
structure with symlinked files (such as a Shaman checkout).
- Better handling of drive letters, and of paths that cross drive
boundaries.
- Better testing of Windows-specific cases when running the tests on
Windows, and of POSIX-specific cases on other platforms.
Thanks to @wisaac for starting this patch in D6676.
Thanks to @jbakker for pointing out the drive letter issue. This fixes
T70655.
The Shaman server is a file storage system that identifies files by
SHA256sum and file length. BAT can send packs there by only uploading
changed/new files. The BAT pack is reproduced at the Shaman server's
checkout directory by creating symlinks to the files in its file
storage.
Retrying sending files:
When we can defer uploading a file (that is, when we have other files to
upload as well, and we could send the current file at a later moment) we
send an `X-Shaman-Can-Defer-Upload: true` header in the file upload
request. In that case, when someone else is already uploading that file,
a `208 Already Reported` response is sent and the connection is closed.
Python's Requests library unfortunately won't give us that response if
we're still streaming the request, and raise a ConnectionError exception
instead. This exception can mean two things:
- If the `X-Shaman-Can-Defer-Upload: true` header was sent: someone else
is currently uploading that file, so defer it.
- If that header was not sent: that file is already completely uploaded
and does not need to be uploaded again.
Instead of retrying each failed file, after a few failures we now just
resend the definition file to get a new list of files to upload, then
send those. This should considerably reduce the number of HTTP calls
when multiple clients are uploading the same set of files.
The target path is just read as string from the CLI now, to allow more
complex targets (such as URLs) that don't directly map to a path.
The Packer subclass now handles the conversion from that string to a
`pathlib.PurePath`, and specific subclasses & transfer classes can convert
those to a `pathlib.Path` to perform actual filesystem operations when
necessary.
This makes BAT skip assets that are referred to with an absolute path.
It is assumed that the receiver of the BAT pack can access those assets
at the same path.
For this to work well I also had to remove the sorting of blocks in
trace.deps(). The sorting caused the first `yield` to be executed only
after each blend file was opened, which means that the consuming for-loop
takes a long time to hit its first iteration. As a result, it would respond
slowly to abort requests. By not sorting the first `yield` is much sooner,
resolving this issue.
Both the dependency Tracer class and the Packer class now support a
callback object, where the latter is a subclass of the former.
For file transfers running in a separate thread, there is a thread-safe
wrapper for progress callbacks. This wrapper can be called from any thread,
and calls the wrapped callback object from the main thread. This way the
callback implementation itself doesn't have to worry about threading
issues.
