TL;DR
- Filenames with consecutive dots no longer lose their extension. Reported by @zakimimit in #754. A name like
1. Hello World..mp4was being rewritten bycleanFilenameto1. 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.getFolderNodessilently discarded any node whoseksegment failed to decrypt the attribute payloada, producing a "missing entries with no clue why" folder dialog. Now aWARNINGis logged with the folder id and node handle, so partial-tree reports are diagnosable frommegabasterd.log. - Folder-link dialog no longer NPEs in the thread pool when closed mid-load. Closing
FolderLinkDialogwhile_loadMegaDirTreewas still running calleddispose()(whichsetModel(null)'d theJTree), and the queued_genDownloadLiksthen tripped onfile_tree.getModel().getRoot(), swallowing the NPE inTHREAD_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.mp4 → a.b.c.mp4, foo...bar.mp4 → foo.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.
getFolderNodeswalks eachksegment and tries to decrypt the attribute payloadawith 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 aWARNINGcarrying the folder id, the node handle and the offending fullk, 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'sdispose()overrides nulls theJTreemodel (file_tree.setModel(null)). The async load runs inTHREAD_POOLand, when_loadMegaDirTreefinished, called_genDownloadLiksunconditionally on_mega_error == 0. If the user had already closed the dialog, that GUIRun then hitfile_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 existingexitflag and returns early, skipping_genDownloadLiksand 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 stalecurrent_idwhile climbing the tree — it still works because the subfolder node itself is eventually iterated and setsroot, 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_genDownloadLikson 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.