Releases: tanaikech/goodls
v3.4.0
What's Changed in v3.4.0
- Enterprise Proxy & Network Resilience: Introduced
--proxy(-p),--retry, and--retry-delaywith exponential backoff for flawless execution behind firewalls and unstable connections. - Docker & CI Compatibility: Completely resolved
syscall.Stdinhanging issues in headless/non-interactive environments. - Google Colab Support: Added native parsing and transparent downloading for
colab.research.google.com/drive/URLs. - Indestructible Large File Scraper: Upgraded the Google Drive warning bypass with a 4-tier fallback system (including raw HTML regex matching) to combat unannounced DOM changes.
- Developer Tooling: Added
--json(-j) for structured outputs and--verbose(-v) for deep HTTP diagnostics. (The CLI version flag was migrated to-V). - MCP Schema Expansion: Autonomous AI agents can now dynamically supply proxy settings and retry counts via the
downloadMCP tool.
v3.3.1
Release Notes - v3.3.1
Features & Improvements
-
Native MCP Server Capabilities (
mcpsubcommand)
goodlsnow functions as an autonomous tool for LLMs via the Model Context Protocol. Features seamless stdio JSON-RPC handshaking, strict prompt fallback controls, and robust capability discovery. -
Asynchronous Architecture & Ping Stabilization
Rebuilt the MCP request loop using Goroutines and Mutex locks to support large file downloads without blocking systempingmessages, completely fixing theconnection closedtimeout issues caused by aggressive clients. -
Intelligent Directory Creation
MCP tool invocations targeting non-existent local paths automatically performos.MkdirAllrecursively to eliminate friction for AI agents. -
Shared Drives API Expansion
Enhanced query logic natively enforcessupportsAllDrives=true, ensuring flawless downloads from enterprise Google Workspace Shared Drives across all fetch behaviors.
v3.3.0
Release v3.3.0
Key Changes and Enhancements
🔄 Interactive and Non-Interactive Conflict Resolution System (--conflict, -cf)
We have introduced a customizable conflict resolution engine to manage situations when a file already exists in the destination folder. You can configure this using the new --conflict (or -cf) flag.
Supported strategies include:
prompt(Default in interactive terminals): Asks the user to choose an action from[s]kip,[o]verwrite,[n]ewer,[r]ename, or[a]bort. It automatically falls back to therenamestrategy in non-interactive / pipeline environments.skip: Skips downloading the file safely (legacy--skipor-sflags map to this automatically).overwrite: Overwrites the existing local file (legacy--overwriteor-oflags map to this automatically).newer: Overwrites the existing file only if the remote file's modification timestamp is newer than the local one. Otherwise, skips the download. If remote time is unavailable, it warns and falls back torename.rename: Automatically renames the file with a timestamp suffix (e.g._YYYYMMDD_HHMMSS). If that also exists, it appends a numeric counter (e.g._1,_2).
📁 Enhanced Directory Handling
Improved stability of concurrent folder downloads by reinforcing the directory-creation pipeline, resolving write conflicts during parallel execution.
Pre-compiled Binaries Included:
13 binaries are pre-compiled and attached to this release for the following environments:
- macOS (Intel & Apple Silicon)
- Linux (386, amd64, arm64, arm7, mips, mipsle)
- FreeBSD (amd64, arm64)
- Windows (386, amd64, arm64)
v3.2.2
v2.0.6
v2.0.5
-
v2.0.5 (March 10, 2023)
- From this version, when the API key is used, the large file is downloaded by the API key. Because the specification for downloading the shared large file is sometimes changed. When the API key is not used, the shared large file is downloaded by the current specification (v2.0.4). If the shared large file cannot be downloaded by the change of the specification on Google's side, please use the API key and test it again. The usage of goodls has not changed.
v2.0.4
-
v2.0.4 (March 9, 2023)
- From January 2024, it seems that the specification of the process for downloading a large shared file on Google Drive has been changed. So I updated goodls to reflect this. The usage of goodls has not changed. In the current stage, when a large share file is downloaded, it is required to click the following button.
<form id="download-form" action="https://drive.usercontent.google.com/download" method="get" > <input type="submit" id="uc-download-link" class="goog-inline-block jfk-button jfk-button-action" value="このままダウンロード" /> <input type="hidden" name="id" value="fileId" /> <input type="hidden" name="export" value="download" /> <input type="hidden" name="authuser" value="0" /> <input type="hidden" name="confirm" value="t" /> <input type="hidden" name="uuid" value="uuId" /> <input type="hidden" name="at" value="some value" /> </form>
In this version, the URL obtained by this click is created, and the created URL is used for downloading it.