github tonikelope/megabasterd v8.41
MegaBasterd 8.41

latest release: v8.42
4 hours ago

TL;DR

  • Filenames with consecutive dots no longer lose their extension. Reported by @zakimimit in #754. A name like 1. Hello World..mp4 was being rewritten by cleanFilename to 1. Hello World__mp4: any run of two or more dots was replaced with __, which destroyed the boundary before the extension and left the file unrecognisable by the OS and media players. The downloaded file now keeps its extension intact (1. Hello World.mp4).
  • Folder-link reader logs dropped nodes instead of silently skipping them. MegaAPI.getFolderNodes silently discarded any node whose k segment failed to decrypt the attribute payload a, producing a "missing entries with no clue why" folder dialog. Now a WARNING is logged with the folder id and node handle, so partial-tree reports are diagnosable from megabasterd.log.
  • Folder-link dialog no longer NPEs in the thread pool when closed mid-load. Closing FolderLinkDialog while _loadMegaDirTree was still running called dispose() (which setModel(null)'d the JTree), and the queued _genDownloadLiks then tripped on file_tree.getModel().getRoot(), swallowing the NPE in THREAD_POOL. The post-load callback now bails out cleanly when the user has already exited.
  • Everything that shipped in 8.40 is included; 8.41 is 8.40 + the changes above. No behaviour changes outside filename sanitization and the folder-link reader path.

New in 8.41

Issue #754 — Filename extension destroyed when the name contains consecutive dots

cleanFilename (used by every download path that derives a local filename from a MEGA n attribute) ran replaceAll("\.\.+", "__") to neutralise .. parent-dir traversal sequences. By the time that line ran, slashes (/, \) had already been stripped from the filename — so .. no longer had any path-traversal effect — but the replacement turned the dot run immediately before the extension into underscores. A name like 1. Hello World..mp4 came out as 1. Hello World__mp4, with no extension and the dot-before-mp4 flattened.

Fix: collapse any run of two or more dots to a single dot rather than to __. The result keeps the extension intact and is still safe against traversal — .. inside a filename can't traverse anywhere, and the same change applied to cleanFilePath (which keeps slashes, since it's a relative path under the download base directory) turns ../foo into ./foo, which resolves harmlessly inside the base.

Trailing-dot stripping on Windows continues to apply, and nested runs collapse the way you'd expect — a..b..c.mp4a.b.c.mp4, foo...bar.mp4foo.bar.mp4, ..hidden.txt.hidden.txt, report.tar.gz unchanged.

Folder links: log dropped nodes and avoid NPE on early close

Two silent-failure paths in the folder-link reader were uncovered by an audit of FolderLinkDialog + MegaAPI.getFolderNodes:

  • Dropped nodes were silent. getFolderNodes walks each k segment and tries to decrypt the attribute payload a with each candidate key. If none works, the node was discarded with no log line at all — so a corrupted entry, or a node shared with a different folder key, made the resulting tree quietly missing files. The else-branch now logs a WARNING carrying the folder id, the node handle and the offending full k, so users hitting "this folder is missing X" can produce a usable bug report.
  • Closing the dialog mid-load NPE'd in the pool. FolderLinkDialog's dispose() overrides nulls the JTree model (file_tree.setModel(null)). The async load runs in THREAD_POOL and, when _loadMegaDirTree finished, called _genDownloadLiks unconditionally on _mega_error == 0. If the user had already closed the dialog, that GUIRun then hit file_tree.getModel().getRoot() with a null model and threw an NPE that only showed up in the log (the user just saw "nothing happened"). The post-load callback now checks the existing exit flag and returns early, skipping _genDownloadLiks and the "Let's dance, baby" button update.

Two further folder-link observations were left in-tree for a future pass and not changed here:

  • _loadMegaDirTree's do-while loop uses a stale current_id while climbing the tree — it still works because the subfolder node itself is eventually iterated and sets root, but it's fragile for #F!FID@SID!K (subfolder) links.
  • _mega_error = mex.getCode() would treat a hypothetical MEGA code 0 as success and run _genDownloadLiks on a bad tree; MEGA always returns negative codes in practice.

Build artefact: MegaBasterd_8.41.jar is the full fat-JAR (-jar-with-dependencies), drop-in replacement for the 8.40 jar.

Don't miss a new megabasterd release

NewReleases is sending notifications on new releases.