[BenjaminDEMAILLE]

Summary

SaveSeuratRds() records where each on-disk layer (BPCells IterableMatrix, DelayedMatrix, ...) lives, and LoadSeuratRds() reopens it from that record. But the record was only ever interpreted from the current working directory, so both ways of saving break as soon as the object is shared or reorganized:

• relative = TRUE writes paths relative to the .Rds, so loading from any other working directory finds nothing;
• relative = FALSE (the default) writes absolute paths, so moving or renaming the folder holding the .Rds and its stores finds nothing.

In both cases the load warns Cannot find any of the layer files specified and returns an object with no layers at all, which is easy to miss.

Reproducer

library(SeuratObject); library(BPCells)
m <- as(matrix(rpois(2400, 1.3), 60, 40), "dgCMatrix")
dimnames(m) <- list(paste0("g", 1:60), paste0("c", 1:40))
store <- tempfile(); write_matrix_dir(m, store)
obj <- CreateSeuratObject(counts = open_matrix_dir(store))

d1 <- tempfile(); dir.create(d1)
SaveSeuratRds(obj, file.path(d1, "o.Rds"), move = TRUE, relative = TRUE)

d2 <- tempfile(); file.rename(d1, d2)          # share / reorganize
setwd(tempdir())                                # load from anywhere else
o <- LoadSeuratRds(file.path(d2, "o.Rds"))
#> Warning: Cannot find any of the layer files specified
Layers(o)
#> NULL

The same happens with relative = FALSE after the folder is moved.

Fix

Resolve each cached path against the directory holding the .Rds before checking whether it exists. .ResolveLayerPaths() tries, in order:

1. the recorded path as-is,
2. the recorded path relative to the .Rds directory,
3. its basename within the .Rds directory.

Objects that have not moved keep loading through the first branch, so existing behaviour is unchanged. Step 2 fixes relative = TRUE; step 3 fixes an absolute path whose store travelled alongside the .Rds, which is exactly the layout SaveSeuratRds(move = TRUE) creates.

Tests

New tests/testthat/test_save_rds.R covers all three cases (relative after a move from another working directory, absolute after a move, and an object that has not moved). Against main it fails 6 assertions; with this change all 11 pass. Guarded with skip_if_not_installed("BPCells").

Notes

• No version bump, to avoid a guaranteed conflict with Add StitchMatrix.DelayedMatrix for DelayedArray-backed layers #295, which already claims 5.4.0.9002. Happy to add one in whichever order suits you.
• Companion to a Seurat-side PR that adds SaveSeurat()/LoadSeurat() single-file bundles for the same problem (Enable Seurat to Handle Ultra-Large Matrices (>2^31 values) seurat#9798).

🤖 Generated with Claude Code

[BenjaminDEMAILLE]

cc @anashen

Small one, and it is a genuine bug rather than a feature: LoadSeuratRds() resolves its cached on-disk layer paths against the current working directory instead of the directory holding the .Rds. So relative = TRUE breaks whenever you load from anywhere else, and relative = FALSE breaks whenever the folder is moved. In both cases the load emits one warning and returns an object with no layers at all, which is easy to miss.

One helper plus one call site, no new dependency. The new test file fails 6 assertions against main and passes 11 with the change, and R CMD check on the branch is Status: OK with no NOTEs.

Related Seurat-side PR: satijalab/seurat#10452.

---

Outside contribution: I am not a member of the Seurat dev team, and this comment is not an official answer from the maintainers.

[BenjaminDEMAILLE]

Superseded by #320, which groups the on-disk layer PRs into one, since they are the same round trip: join, save, reload. The commit is carried over unchanged; closing here to keep the queue down rather than because anything was wrong with it.