Let's break down why your auto-rename functionality is behaving inconsistently, and fix it step by step.

Core Issue Analysis #

You've set mode: "add" and autorename: true, which should reliably create a renamed copy (e.g., document(2).txt) when the target file exists. The inconsistent behavior almost always stems from invalid JSON formatting in your Dropbox-API-Arg header—a common pitfall when manually concatenating JSON strings.

Step 1: Fix the Dropbox-API-Arg Formatting #

Your current code builds the JSON header manually, which will fail silently if req.file.originalname contains special characters (like quotes, backslashes, or even spaces with unexpected encoding). Dropbox will either ignore malformed parameters or fall back to default values (where autorename defaults to false), leading to files being overwritten instead of renamed.

Replace your manual string concatenation with JSON.stringify() to ensure valid, properly escaped JSON every time:

// Build the API argument object first
const dropboxApiArg = JSON.stringify({
  path: `/test/${req.file.originalname}`,
  mode: "add",
  autorename: true,
  mute: false
});

// Update your options with the properly formatted header
let options = { 
  method: 'POST', 
  uri: 'https://content.dropboxapi.com/2/files/upload', 
  headers: { 
    'Authorization': 'Bearer ' + DROPBOX_API_TOKEN, 
    'Dropbox-API-Arg': dropboxApiArg, 
    'Content-Type': 'application/octet-stream' 
  }, 
  body: fs.createReadStream(`uploads/${req.file.originalname}`, {highWaterMark: 256 * 1024}) 
};

Step 2: Verify Parameter Integrity #

To confirm the fix is working, debug the actual Dropbox-API-Arg value being sent:

• Add a console.log(dropboxApiArg) before sending the request to check for valid JSON (validate it using a local JSON tool or built-in browser dev tools)
• Ensure autorename: true is present as a boolean value (not a string like "true"—this is another common mistake that Dropbox will ignore)

Step 3: Rule Out Edge Cases #

If the issue persists after fixing the JSON formatting, check these edge cases:

• Case Sensitivity: Dropbox paths are case-insensitive (e.g., /test/File.txt and /test/file.txt are treated as the same path), but preserves file name casing. Confirm you're not accidentally uploading to a path that only differs in case from an existing file.
• File Metadata Sync: Rarely, Dropbox's server sync might have a short delay. Wait 10-15 seconds after uploading a file before attempting to upload a duplicate to ensure the server recognizes the existing file.
• Check for Existing Files: Before uploading, call the files/get_metadata endpoint to verify if the target path already exists. This will help you confirm whether Dropbox should trigger the auto-rename logic for each upload.

Example of Expected Behavior #

When auto-rename works correctly, your API response will include a name field with the renamed file (e.g., Screen Shot 2018-01-09 at 15.35.16(2).png) and a new unique id (not an updated rev like your problematic response shows—your current response indicates the existing file was overwritten, which happens when autorename is not properly enabled).

内容的提问来源于stack exchange，提问作者Skywalker