mirror of
https://github.com/bulwarkmail/native.git
synced 2026-11-04 00:06:53 +00:00
Linus Rath
3f4a81b7ad
Files in the app assumed Stalwart 0.16 in several places: - Stalwart 1.0 lists the owner's folders above a node shared with the user, without dates and with every right false. The app took the owner's top folder for the shared root, so the folder actually shared sat several levels down, under folders where rename, delete and move could only fail. Those placeholders are now left out of the root and of folder listings. - A node counted as a folder when it had no blobId, so 1.0's symlinks showed up as empty folders that could be opened. Listings ask for `nodeType` (returned since 0.16.6, never sent in FileNode/set), and a symlink is an inert row with a link icon: it can be renamed, moved and deleted, but not opened, downloaded, duplicated or shared. - Only "/" was checked in names, and uploads were not checked at all, so `<>:"\|?*` already failed on 0.16. New folder and rename now apply the naming rules from the filenode capability plus 1.0's stricter ones (control characters, 255 bytes, reserved stems such as `con.txt`) and say what is wrong. Uploaded names are made acceptable instead: `con.txt` becomes `con_.txt`, also on 0.16.6 to 0.16.23. - One refused file stopped a whole upload. The batch now goes on and reports the files that failed at the end. - Every media type over 30 characters, which is every Office document, was stored as application/octet-stream. New files get the bare lowercase media type 1.0 requires, and no `size`, which 1.0 refuses when it differs from the blob. - File errors keep their JMAP type, and the alerts say why an action failed: too many files or folders (`overQuota`), folders nested too deeply, a refused name, missing rights, or a file too large.
54 lines
2.1 KiB
TypeScript
54 lines
2.1 KiB
TypeScript
// Why a FileNode write failed, from the SetError the files API threw, for the
|
|
// Files alerts to explain (webmail lib/file-errors.ts).
|
|
|
|
import { JMAPMethodError, jmapErrorProperties } from '../api/jmap-result';
|
|
import type { TranslateFn } from '../stores/locale-store';
|
|
|
|
export type FileErrorKind = 'overQuota' | 'tooDeep' | 'invalidName' | 'forbidden' | 'tooLarge';
|
|
|
|
export function fileErrorKind(error: unknown): FileErrorKind | null {
|
|
if (!(error instanceof JMAPMethodError)) return null;
|
|
switch (error.type) {
|
|
// Stalwart 1.0, once an administrator limits files or folders per account.
|
|
case 'overQuota':
|
|
return 'overQuota';
|
|
// 1.0 for content over 4 GiB.
|
|
case 'tooLarge':
|
|
return 'tooLarge';
|
|
case 'forbidden':
|
|
return 'forbidden';
|
|
case 'invalidProperties': {
|
|
const properties = jmapErrorProperties(error);
|
|
if (properties.includes('name')) return 'invalidName';
|
|
// `parentId` is refused for other reasons too (the folder is gone, a
|
|
// folder moved into itself); only 1.0's description, "Maximum folder
|
|
// depth exceeded.", tells depth apart.
|
|
if (properties.includes('parentId') && /depth/i.test(error.message)) return 'tooDeep';
|
|
return null;
|
|
}
|
|
default:
|
|
return null;
|
|
}
|
|
}
|
|
|
|
/**
|
|
* The text an alert shows for a failed file action: what the server's
|
|
* refusal means when it is one of the known ones, else its own message.
|
|
*/
|
|
export function fileErrorMessage(error: unknown, t: TranslateFn): string {
|
|
switch (fileErrorKind(error)) {
|
|
case 'overQuota':
|
|
return t('files.error_over_quota', 'You have reached the limit on files or folders. Delete some and try again.');
|
|
case 'tooDeep':
|
|
return t('files.error_too_deep', 'Folders cannot be nested this deeply.');
|
|
case 'invalidName':
|
|
return t('files.error_invalid_name', 'The server does not accept this name.');
|
|
case 'forbidden':
|
|
return t('files.error_forbidden', 'You do not have permission to do this here.');
|
|
case 'tooLarge':
|
|
return t('files.error_too_large', 'This file is too large for the server.');
|
|
default:
|
|
return error instanceof Error ? error.message : String(error);
|
|
}
|
|
}
|