[PerryLink]

What

BaseArchiver.extract_item() decides whether an extraction failure was caused by the Windows
260-character MAX_PATH limit like this:

if IS_WINDOWS and (len(src_path) + len(dest_dir) > 260):
    raise WindowsLongPathError(src_path, dest_dir) from exc

The real on-disk path is dest_dir + os.sep + src_path, not the sum of the two lengths, and
dest_dir is not normalised — unpack() accepts a relative destination. So the check under-counts:
the library misses the case it exists to detect, and the user gets a bare FileNotFoundError
([WinError 3]) instead of the actionable "enable long paths" message.

The change

Compare the length of the path that will actually be created:

len(os.path.join(os.path.abspath(dest_dir), src_path)) > 260

One expression, no new validation, the threshold is unchanged.

Verification

Reproduced on a host whose CPython is not long-path aware (a small launcher loading the stock
python312.dll), so the OS itself refuses the path — no monkeypatching:

• 240-character cwd, relative dest_dir, 84-character tar member: the old formula computes 90
  (≤ 260) while the real path is 332 characters;
• before: exit 2 with a bare [WinError 3] ... surfaced as FileNotFoundError;
• after: exit 0 and WindowsLongPathError with the "enable long paths" hint.

A control case with a genuinely short path still raises the original FileNotFoundError, so the new
check does not swallow other failures, and a portable variant of the harness covers 333/482-character
paths with LongPathsEnabled=1.

black is clean on the changed file.

The CLA has been signed.