files-community/Files · error · Exception

The following properties failed to save: {failedProperties}

Error message

The following properties failed to save: {failedProperties}

What it means

A plain System.Exception thrown by CombinedFileProperties.SyncPropertyChangesAsync (line 124) after one or more calls to BaseStorageFile.Properties.SavePropertiesAsync threw during a multi-file property save. Each failure is appended to a string as "filename: propertyname" and the aggregated list is rethrown once, so a multi-select Apply reports every failure together. The original exception is swallowed by a bare catch{} (line 113-116), so the underlying HRESULT/exception type (UnauthorizedAccessException, FileNotFoundException, E_INVALIDARG, property-handler-not-registered, etc.) is lost — only the human-readable file:property list survives.

Source

Thrown at src/Files.App/ViewModels/Properties/Items/CombinedFileProperties.cs:124

							try
							{
								if (file.Properties is not null)
								{
									await file.Properties.SavePropertiesAsync(newDict);
								}
							}
							catch
							{
								failedProperties += $"{file.Name}: {prop.Name}\n";
							}
						}
					}
				}
			}

			if (!string.IsNullOrWhiteSpace(failedProperties))
			{
				throw new Exception($"The following properties failed to save: {failedProperties}");
			}
		}

		public async Task ClearPropertiesAsync()
		{
			var failedProperties = new List<string>();
			var files = new List<BaseStorageFile>();
			foreach (var item in List)
			{
				BaseStorageFile file = await FilesystemTasks.Wrap(() => StorageFileExtensions.DangerousGetFileFromPathAsync(item.ItemPath));

				if (file is null)
					return;

				files.Add(file);
			}

			foreach (var group in ViewModel.PropertySections)

View on GitHub (pinned to 68c68a58d4)

Solutions

Make sure each target file is writable and not locked before applying: clear the read-only attribute, close the application holding the file, and confirm the user has write permission on the path.
Confirm the property is applicable to every selected file's type — the property list from RetrieveAndInitializePropertiesAsync is already filtered per extension, so only set properties that appear (non-read-only) for each file; do not assume a property valid for one file type applies to all in a mixed selection.
For network/cloud locations, hydrate placeholders (OneDrive) or copy the file locally before editing properties, since non-NTFS volumes often lack the property store.
Treat the reported file:property list as authoritative: it tells you exactly which (file, property) pairs failed — retry just those after fixing the per-file blocker rather than re-applying all.
Improve diagnostics by replacing the bare catch{} (line 113) with catch (Exception ex) that logs ex (HRESULT + type) alongside the file:property, so the swallowed root cause is recoverable.

Example fix

// before
try
{
    if (file.Properties is not null)
        await file.Properties.SavePropertiesAsync(newDict);
}
catch
{
    failedProperties += $"{file.Name}: {prop.Name}\n";
}

// after
try
{
    if (file.Properties is not null)
        await file.Properties.SavePropertiesAsync(newDict);
}
catch (Exception ex)
{
    App.Logger?.LogWarning(ex, "SavePropertiesAsync failed for {File}.{Prop}", file.Name, prop.Name);
    failedProperties += $"{file.Name}: {prop.Name}\n";
}

Defensive patterns

Strategy: try-catch

Validate before calling

// Per-file gate before SavePropertiesAsync in the multi-select save loop
foreach (var file in files)
{
    if (file is null || file.Properties is null) continue;

    var attrs = file.Attributes;
    if (attrs.HasFlag(FileAttributes.ReadOnly)) { /* skip or prompt */ continue; }

    // Skip properties not applicable to this file's type — only set those
    // present (and non-read-only) in its own retrieved property list.
}

Try / catch

// Wrap SyncPropertyChangesAsync at the call site; parse the file:property list
try
{
    await combined.SyncPropertyChangesAsync();
}
catch (Exception ex) when (ex.Message.StartsWith("The following properties failed to save:"))
{
    // ex.Message contains "filename: propertyname" per line — surface to user,
    // retry the unaffected subset, or fix per-file blockers.
    await ShowPropertySaveFailuresAsync(ex.Message);
}

Prevention

Clear read-only / confirm write ACL on selected files before opening the Properties pane.
Avoid mixing unrelated file types in a multi-select property edit — a property valid for one extension often is not backed for another.
For network/cloud files, hydrate or copy locally before editing properties.
Replace the bare catch{} at CombinedFileProperties.cs:113 with catch (Exception ex) that logs ex, so the swallowed HRESULT/type is recoverable for support.

When it happens

Trigger: User selects multiple files, edits a property in the Details/Properties pane, and applies; for at least one selected file the SavePropertiesAsync call at line 110 throws. Concrete causes: file is read-only or the user lacks write ACL; file is open/locked by another process; the property is not backed by the file's shell property handler (e.g. setting System.Photo.EXIF on a .txt); the supplied value violates the property's type or range; file lives on FAT32/exFAT/network share with no NTFS property store; cloud placeholder (OneDrive) not hydrated.

Common situations: Multi-selecting files of mixed types and setting a property only some support; files on SMB/network shares with restricted or absent property handlers; files owned by another user or in a protected directory; antivirus or indexer locking the file during write; editing properties on a file still being written by another app; setting read-only system properties that the UI allowed because IsReadOnly wasn't set.

Related errors

AI-assisted analysis of files-community/Files@68c68a58d4 (2026-08-13). Data as JSON: /api/errors/94b632cc15d6f492. Report an issue: GitHub.