loaddata fails when a directory in the fixture path contains a dot

[Alisson Silveira]

How to reproduce:

Create a fixture in a directory containing a dot, for example:

fixtures/fix.v1/data.json

Run (without specifying the file extension):

python manage.py loaddata fixtures/fix.v1/data

This raises:

CommandError: Problem installing fixture 'fixtures/fix': v1/data is not a known serialization format.

This occurs when a directory in the fixture path contains a dot, as the full path is incorrectly split on "." instead of operating on the file name.

Expected behavior: Django should correctly determine the fixture format based on the file name and load the fixture successfully, ignoring dots in directory names.

A fix has been identified and will be submitted in a pull request.

[Alisson Silveira]

Pull request: ​https://github.com/django/django/pull/21213

[Gert Burger]

Tested this on stable/6.0.x and 5.2.11, as reported, if the fixture extension is not specified then any other dot in the path will incorrectly be considered the separator for the extension.

[Sarah Boyce]

Thank you! I think this is a bug worth addressing.
My only concern was whether this could create any path traversal issues allowing something like fixtures/../secret.json but I think this would be out of the scope of security issues anyway. See ​https://docs.djangoproject.com/en/6.0/internals/security/#how-does-django-evaluate-a-report

[Alisson Silveira]

Replying to Sarah Boyce:

Thank you! I think this is a bug worth addressing.
My only concern was whether this could create any path traversal issues allowing something like fixtures/../secret.json but I think this would be out of the scope of security issues anyway. See ​https://docs.djangoproject.com/en/6.0/internals/security/#how-does-django-evaluate-a-report

Thanks for your feedback, Sarah! I can provide a bit more context for the record.

I decided to use a PurePath object to prevent any filesystem access, since this method only needs to parse the filename. The filename is the only piece of information being extracted and modified from the filepath. In contrast, the current approach relies on rsplit() directly on the file path string, which could potentially introduce security issues if the path is manipulated. Using PurePath makes the intent clearer and provides safer path handling.

Since this was a bug I encountered in a production system, my fix is specifically focused on addressing that issue. However, I’d be more than happy to address any additional fixes or improvements related to this area if needed. Please let me know if you’d like me to explore any further improvements here.