BuildScriptPackedMode fails due to IO exception when particular assets are "Packed Separately"

Unity Engine
,
1

Summary
I’ve found an error that causes addressable builds to fail using default BuildScriptPackedMode build script.
The failure occurs when particular assets are added to a “Packed Separately” addressable group.

Investigation
I extracted the addressables package in order to modify the source code for testing purposes and found the error is logged at BuildScriptBase.cs at line 95 (in the catch block). This occurs after a DirectoryNotFoundException is thrown at BuildScriptPackedMode.cs line 982. I confirmed via logs that both the source and destination path strings are non-empty and look no different than when a non-bugged asset is built and this step succeeds.

Notes
There’s nothing noticeably wrong with the asset’s metadata - it looks the same as other files that don’t produce this issue.
I’ve tried manually changing the asset guid, deleting & restoring it from source control, and even completely purging the Library folder and reimporting the entire project. Despite all these steps, the same assets continue to not work on my machine.
The problematic assets differ between machines. One asset that does not work on my machine will build just fine on our build machines, however other assets will instead cause this issue.

Reproduction note
Unfortunately I’m unable to create a minimum reproduction project to upload for testing due to the reasons above.

Environment
I’m running Unity 2020.3.26f1.
This issue occurs on Addressables version 1.18.19 and 1.19.18.
I’m targeting Android.

2

Here’s the path arguments passed to File.Move when the exception occurs:
srcPath:
Temp/com.unity.addressables/AssetBundles\82aea9abdae89172c3d764b914c0f6cd.bundle

destPath:
Library/com.unity.addressables/aa/Android/Android\game_scenes_tracks_farm_common_bugged_assets_assets/game/models/props/chainlinkfence/materials/chainlinkfence_colour_mobile.mat_4f90753b1c1a738d0d9e7b3ef2fe64cb.bundle

3

Sorry, this forum won’t let me edit my above comment, so here’s some additions…

Logs show that the source path is fine. The destination path is the issue, despite Directory.Exists returning true. I’m guessing this could mean there’s a problem with the file name itself or it’s a permissions issue, etc.

Here’s my modified code I added to BuildScriptPackedMode.cs, replacing line 982

try
{
    File.Move(srcPath, destPath);
}
catch (Exception)
{
    Debug.LogError($"srcPath '{srcPath}'");
    Debug.LogError($"destPath '{destPath}'");

    try
    {
        var b = File.ReadAllBytes(srcPath);
        Debug.LogError($"Successfully read bytes from source path {b?.Length ?? -1}");
    }
    catch (Exception e1) { Debug.LogError($"Read from source failed ({e1.GetType()})"); }

    Debug.LogError($"Dest directory exists: {Directory.Exists(new FileInfo(destPath).Directory.FullName)}");

    try
    {
        File.WriteAllText(destPath, "foo");
        Debug.LogError($"Successfully wrote foo to dest path");
    }
    catch (Exception e2)
    {
        Debug.LogError($"Write to destination failed ({e2.GetType()})");
    }

    throw;
}
4

Final addition for this thread:
I’ve now reliably reproduced the problem and reported a bug. It’s related to file path length, hence different results on different machines (Unity project was at different path on disk).

I’ve made a new forum post with more accurate details here: