The reason most software is not "XDG-compliant" is because most software predates the XDG basedir spec which only came into existence in 2021 (edit: oops, that's just version 0.8; version 0.6 was available in 2003)
It will be nice for software, as it updates, to support this standard which seems to be gaining adoption, and it will make users homedirs much cleaner. But it's most important for software to _keep working_, and have a migration path that doesn't lose the user's config or end up with two configs and not have a clear rule on which one it will use.
I think it is possible for software to keep working and I can think of many ways to implement automatic "migration", which is essentially just copying files to the new directory (or just do a move operation which is atomic) and then deleting the previous directory if the copy was successful[1], and if one wants, could create a compressed backup of the directory prior to doing that.
[1] Could (and should) implement a verification step as well.
> which is essentially just copying files to the new directory and then deleting the previous directory if the copy was successful
And deleting the partially copied data if the copy wasn’t successful, and making sure “just copying files to the new directory” didn’t overwrite data, and probably a few more tricky scenarios, e.g. ones involving access rights.
Also, if you think it could be a directory rename, there are tricky corners there, too. How do you determine whether source and target are on the same disk, for example?
It _is_ possible, but doing it robustly is far from trivial.
You are listing edge cases that exist, but the relevant question is whether they meaningfully apply to Firefox profile migration on typical systems.
Same-disk detection can be done through stat() on both paths and comparing st_dev, which is trivial. But more importantly, why does this matter for migration? If it is cross-filesystem, copy and move works fine. If you are concerned about atomicity, that is a different problem, but Firefox profiles are not typically manipulated concurrently during a migration that happens once at startup.
Partial copy cleanup is reasonable, but again, context matters. For a one-time migration triggered at browser start with exclusive access to the profile, you verify checksums or sizes post-copy, and if verification fails, you do not delete the source. User gets an error, tries again later. Not complex.
As for overwrites: do not overwrite if target exists. Check once before starting. If the XDG path already has data, skip migration entirely or prompt. This is not a continuous sync operation.
FWIW "cp -a" preserves access rights on Unix. On Windows, ACLs can be trickier but for user-owned profiles it is usually a non-issue.
The real complexity in robust file operations show up with network filesystems (SMB, NFS), concurrent access patterns, or where atomicity guarantees are critical (and a move operation is indeed atomic, assuming typical systems). For a single-user profile migration that happens once with exclusive lock? The corner cases you mentioned are either straightforward to handle or do not apply.
