What does HRESULT 0x80270260 (E_SKYDRIVE_ROOT_TARGET_FILE_SYSTEM_NOT_SUPPORTED) mean?

 
Previous Next
E_APPLICATION_TRIAL_LICENSE_EXPIRED E_SKYDRIVE_ROOT_TARGET_OVERLAP

E_SKYDRIVE_ROOT_TARGET_FILE_SYSTEM_NOT_SUPPORTED

The scope of E_SKYDRIVE_ROOT_TARGET_FILE_SYSTEM_NOT_SUPPORTED is Windows cloud-file and sync-engine infrastructure: the selected sync-root target is not on a supported NTFS file system. Preserve 0x80270260 beside the returning call before cleanup or retry creates a more generic secondary failure.

Wrong turns

When it is returned, ROOT_TARGET_VOLUME_ROOT_NOT_SUPPORTED rejects the root directory itself even on a suitable volume; this code rejects the file-system type.

Do not reformat or convert a volume before preserving data and confirming product support.

Object and state boundary

When it is returned, a Windows sync engine coordinates local NTFS objects, provider metadata, remote identifiers, quota and naming rules, placeholder hydration, network authentication, and asynchronous upload or download state. During a this result investigation, the same Explorer action can cross several of those boundaries, so diagnosis must retain the first failing stage rather than treating every code as a generic connectivity problem.

During a this result investigation, legacy SkyDrive root relocation depends on NTFS semantics used for metadata, indexing, security and integration. A reachable volume is not sufficient when its file system lacks the required contract.

The first owner to inspect is the local sync root, placeholder state, file-system operation, provider request, network exchange, account policy, or remote storage operation that produced the HRESULT.

Capture before retry

CaptureDiagnostic value
Target volume and file-system type for it.This separates caller input from environment and service state and helps test the Windows cloud-file and sync-engine infrastructure boundary.
Mount point and volume identity for it.This provides a stable comparison across retries or another machine and helps test the Windows cloud-file and sync-engine infrastructure boundary.
Encryption or removable-media status for it.This identifies the exact object or resource generation involved and helps test the Windows cloud-file and sync-engine infrastructure boundary.
Existing sync-root registration for it.This places the failure on the lifecycle or transaction timeline and helps test the Windows cloud-file and sync-engine infrastructure boundary.

Controlled comparisons

ControlInterpretationHold constant
Same input, fresh object or connectionIf the result disappears, retained lifecycle or ownership state is implicated.While diagnosing this result, keep the original data, account, device, or timeline parameters unchanged.
Same object, reduced operationIf the result follows one specific transition, statement, file, or ceremony step, the failure is localized.While diagnosing this result, remove only unrelated work and keep the first failing boundary visible.
Same stable item ID, second supported pathA change separates local file-system/provider state from remote service state.While diagnosing it, keep account, remote version and client build fixed.

Step-by-step investigation

The investigation should change one variable at a time and keep the original failing sample.

  1. First: Confirm the volume with system APIs, not path appearance.
  2. Next: Choose an NTFS folder on a supported local volume.
  3. Then: Test permissions and indexing before migration.
  4. Finally: Move through the supported client workflow.

Closure criteria

Closure for it requires the new NTFS folder registers as a sync root and completes an upload/download cycle after restart; then repeat the next lifecycle operation to detect stale state.

Technical references

The references below define the API family or storage/protocol behavior used to interpret it.


Looking for a different code? Search another status or error code.