[Bug] `olcli push` does not reliably sync nested directories and may flatten paths into the project root

[Poseidon-fan]

Summary

When using olcli to sync an Overleaf project that contains nested directories such as data/, figure/, and font/, push reports success but does not reliably update remote files under subdirectories.

In addition, push --all --probe-folder may upload some nested files into the project root instead of preserving their relative paths, which leaves the remote project in an inconsistent state.

I also observed that locally generated build artifacts such as downloaded PDFs and log files can be uploaded to the remote project unintentionally.

Environment

• olcli version: 0.1.6
• Install method: Homebrew
• OS: macOS
• Node.js: v25.9.0
• Overleaf: cloud-hosted project

All identifiers below are sanitized.

Project layout

Minimal structure of the local project:

project/
  .olcli.json
  sample-bachelor.tex
  data/
    chapter1-intro.tex
    chapter2-config.tex
    chapter3-download.tex
    chapter4-basic.tex
    chapter5-usage.tex
    reference.tex
    bachelor/
      bachelor_info.tex
  figure/
    arch.png
  font/
    SimHei.ttf

Later, two new files were added locally:

data/chapter6-problem.tex
data/chapter7-plan.tex

Steps to reproduce

1. Start from a synced Overleaf project with nested directories.
2. Modify existing files under data/, for example:
   • data/chapter1-intro.tex
   • data/chapter2-config.tex
   • data/reference.tex
3. Add new files under data/, for example:
   • data/chapter6-problem.tex
   • data/chapter7-plan.tex
4. Run:

olcli push .

5. Verify remote state by downloading files back or listing project files:

olcli push --dry-run .
olcli info
olcli download data/chapter1-intro.tex <PROJECT_ID> -o /tmp/ch1.tex
olcli download data/chapter6-problem.tex <PROJECT_ID> -o /tmp/ch6.tex

6. As a fallback, run:

olcli push --all --probe-folder .

7. Inspect the remote project again with:

olcli info

Expected behavior

• olcli push . should upload modified files in nested directories correctly.
• Newly added files under nested directories should appear remotely at the same relative paths.
• olcli push --dry-run . after a successful push should show no pending uploads for those files.
• olcli push --all --probe-folder . should preserve directory structure and should not upload files into the project root unless they are actually in the root locally.
• Temporary probe files should not remain in the remote project.
• Build artifacts such as downloaded PDFs and logs should ideally be ignored, or there should be a documented way to exclude them.

Actual behavior

1. push reports success, but nested files are not actually updated remotely

Running:

olcli push .

returned a success message similar to:

✔ Uploaded 11 file(s) to "<SANITIZED_PROJECT_NAME>"

However:

• sample-bachelor.tex on the remote side was updated
• data/chapter1-intro.tex still had the old content
• data/chapter6-problem.tex did not exist remotely

So the push appeared successful, but remote nested files were not in sync.

2. push --dry-run still shows the same files as pending immediately after a successful push

After olcli push ., running:

olcli push --dry-run .

still showed the same nested files as pending upload, including files that had supposedly just been uploaded.

This suggests the previous push did not complete correctly for those files.

3. push --all --probe-folder may flatten nested paths into the project root

Running:

olcli push --all --probe-folder .

produced output similar to:

✔ Found root folder ID: <SANITIZED_FOLDER_ID>
✔ Uploaded 29 file(s) to "<SANITIZED_PROJECT_NAME>"

After that, olcli info showed both the correct nested files and unexpected duplicates in the project root.

For example, the remote project ended up containing both:

/data/chapter1-intro.tex
/data/chapter2-config.tex
/data/reference.tex
/figure/arch.png
/font/SimHei.ttf

and also unexpected root-level files such as:

/chapter1-intro.tex
/chapter2-config.tex
/chapter6-problem.tex
/chapter7-plan.tex
/reference.tex
/arch.png
/SimHei.ttf

This makes it look like path information was lost for some uploads.

4. Probe temp file is left in the remote project

After using --probe-folder, olcli info also showed a temporary file like:

/.olcli-probe-<timestamp>.tmp

remaining in the remote project.

5. Local build artifacts can be uploaded unintentionally

After running commands like:

olcli pdf
olcli output log

local files such as a downloaded PDF and a log file were created in the project root.

If olcli push . was run afterward, those files were uploaded to the remote project as regular project files.

Why this is problematic

• It is difficult to trust push success output for projects with nested folders.
• Remote projects can become polluted with duplicate root-level files.
• New chapter files or assets may appear to be synced but are not actually usable by the remote build.
• The remote project can accumulate temporary probe files and local build artifacts.
• This is especially risky for LaTeX projects, where correct relative paths are essential.

Suggested directions

Possible fixes that would help:

• Ensure push preserves relative paths for all nested files.
• Ensure newly added files under nested directories are created in the correct remote folder.
• Make push --dry-run reflect the actual synced state after a successful push.
• Remove probe temp files automatically after folder probing.
• Ignore common local build artifacts by default, or support an ignore file / exclude patterns.

Additional notes

• This issue was observed on a real Overleaf project, but all project names, IDs, file contents, and local paths in this report have been sanitized.
• I can provide more sanitized command output if helpful.

[aloth]

Thanks for the detailed report - this was very helpful.

This should now be fixed in v0.1.7:

https://github.com/aloth/olcli/releases/tag/v0.1.7

The 0.1.7 release includes fixes for the two main issues you described:

• preserving nested folder structure during push
• preventing generated output.pdf from being uploaded back during push / sync

This was validated against the real e2e suite before release, including push/sync flows and stale folder recovery.

If you’re able to test with v0.1.7, I’d appreciate a quick confirmation. If you still see:

• flattened nested paths
• duplicate files appearing in the project root
• probe temp files left behind
• other build artifacts being uploaded unexpectedly

please comment with the exact repro on 0.1.7 and I’ll treat that as a follow-up bug.

Thanks again for taking the time to write this up so clearly.