If the configured log path (or the default exe-adjacent path) isn't
writable, we now try the current user's Desktop first — that's where
users actually look — and only fall back to AppData if Desktop is
also unavailable. The daily-log filename suffix is preserved on the
fallback file so the format stays consistent.
A backup made on 'Server A' carries absolute paths (logFilePath,
folderMonitor.folderPath, pendingQueue file paths) that do not exist
on 'Server B' — leading to silent log-write failures, folder-monitor
start errors on missing directories, and queue jobs pointing at
non-existent files.
On import, now:
- clear logFilePath if its parent directory doesn't exist here
- clear folderMonitor.folderPath + disable it if the directory is missing
- clear pendingQueue (queue state is inherently per-machine)
Also harden startup: folder-monitor auto-start now verifies the path
exists and persists enabled=false if not, so one missing-path launch
doesn't keep retrying forever.
Adds an 'Exportieren' button next to 'Alle entfernen' that writes a
pipe-delimited log of every row currently shown in the recent-uploads
panel — so session data doesn't get lost if the log file path is wrong.
Also fixes appendUploadLog silently failing: if the configured path is
unwritable (e.g. C:/Users/<nonexistent>/...), entries now go to
<userData>/fileuploader-fallback.log and the renderer warns once.
Try app-internal key first (new format); on failure, signal the
renderer to prompt for the old password and retry. Lets users import
.mhu files that were exported with a custom password in v2.7.6 or
earlier without downgrading.
File stays AES-GCM encrypted with a fixed app-internal key — opaque
without the app, which is the only protection we actually need for
locally-stored API keys. Removes the modal and both password dialogs.
/upload/complete was failing (non-JSON response, missing fileId, or
post-processing timeout) after all bytes were already on the server,
causing upload-manager to retry the entire multi-GB upload — which
corrupts the server-side file since two uploads end up interleaved.
Now /complete failures are swallowed and sessionId is used as the
file_code fallback. Upload is considered done once all chunks are in.
Upload completes on server but file is still being processed, so
share-link fails. Retry up to 6x with backoff; on final failure, use
fileId-based fallback URL instead of throwing — prevents upload-manager
from retrying the entire multi-GB upload.
Adds a red 'Alle entfernen' button next to the 'Zuletzt erzeugte
Upload-Links' label that clears all entries from the recent files
panel after confirmation.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Drag the right edge of any queue column header to resize it. Cursor
changes to col-resize on hover. Widths are saved to localStorage and
restored on next launch.
- Resizer handles in all 8 queue table columns
- Resize state visible via dragging class + body cursor override
- Min width 40px, no max (table can scroll horizontally)
- Click on resizer doesn't trigger column sort
- Persisted across sessions via localStorage
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- addJobs injects new tasks into running batch (verified concurrent execution)
- addJobs rejects duplicate jobIds already in batch
- addJobs returns added=0 when not running
These tests verify the fix in v2.6.3 (files added during upload now
get injected into the running batch via addJobsToBatch).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
When user added new files during an active upload (drag-drop, picker
or folder monitor with pre-selected hosters), the files were pushed to
selectedFiles but NO queue jobs were created (because updateUploadView
skips buildQueuePreview during uploading=true).
The files briefly showed up via folder monitor's direct buildQueuePreview
call, but then handleBatchDone → syncSelectedFilesFromQueue removed them
from selectedFiles because they had no queue jobs.
Now: applyHosterSelection() and folder monitor both detect added files
during upload and:
1. Build preview jobs for the new files
2. Reset them to 'queued' status
3. Inject them into the running batch via addJobsToBatch IPC
The upload-manager has duplicate protection so re-injection is safe.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Previously, clicking 'Ausgewählte starten' on 'Wartet' jobs during an
active upload just showed a toast. But the jobs might NOT actually be
in the batch (skipped during task building).
Now: ALL selected queued/error/aborted jobs are sent to addJobsToBatch.
The upload-manager has duplicate protection (checks jobAbortControllers)
so jobs already in the batch are skipped. Jobs NOT in the batch get
added and start uploading immediately.
Toast now shows exact counts: "X hinzugefügt, Y waren schon im Batch"
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- 'Ausgewählte starten' on already-queued jobs during upload now shows
toast: "X Jobs warten bereits auf ihren Upload-Slot"
- Only error/aborted/skipped jobs are added to the running batch
(prevents duplicate task creation for already-queued jobs)
- Toast confirms when error jobs are added to batch
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
When the app restarts with a restored queue, it now automatically
reads all fileuploader.log files and removes jobs that were already
successfully uploaded in a previous session.
This prevents re-uploading files that completed before a crash/close.
The dedup runs silently before the UI renders — no user action needed.
Also adds 'read-own-upload-log' IPC that reads all log variants
(base + daily logs) without file picker.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
buildQueuePreview() was re-creating removed jobs because they weren't
in _completedUploadKeys. Now log-imported file+hoster combos are added
to _completedUploadKeys so they stay removed.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
