Hi @ArielLeyva,

I actually worked on the same issue a few days ago and just submitted a PR for it: #5884.

It's unfortunate that I didn't see your work earlier

@ArielLeyva Thanks for your PR. That is a pity that we worked with @geourjoa at exactly the same time!

I think that your code has performance issues when you upload a deeply nested structure like:

foo/
  bar/
    baz/
      qux/
        file.txt

The browser's file input gives you a flat list of files with relative paths. The client iterates over each file and makes an upload request (either POST or TUS) with the full destination path.

With skip=true, every single file and folder would hit the server, and the server checks if the destination already exists before writing. This means:

If bar/ doesn't exist on the server at all, then none of the nested files can possibly conflict. Yet the client would still:

• Send foo/bar/baz/qux/file.txt with skip=true
• Server checks existence → doesn't exist → writes it

This is fine for correctness (it works), but it's wasteful when you could short-circuit: if a parent directory doesn't exist, you know nothing inside it conflicts, so you could skip the per-file existence check and just upload everything directly.

This a big problem for our use case where hundreds or thousands of nested folders are uploaded.

If it is not to much of a burden, could you have a look to @geourjoa draft PR #5884

It implements a tree structure and a recursive function over this tree so it does not check for subfolders if it discovers that a parent does not exist on the server.

Also, it adds a "Resume previous transfert" that ignores existing files, except if they are smaller on the server. Indeed, if a big transfert is abruptly interrupter, some files will be partially uploaded and smaller on the server than they should be.

I'm not sure but it seems that Anthony's code is more concise (no changes in the backend) and yet more efficient than this proposal. I might be mistaken here and it is not at all to trash talk this contribution that is very welcome :-)

If you are interested in seeing PR #5884 in action, we have a demo here: https://filebrowser-fix.tetras-libre.fr

Please comment here and I will send the credentials in DM.

@ArielLeyva Thanks for your PR. That is a pity that we worked with @geourjoa at exactly the same time!

I think that your code has performance issues when you upload a deeply nested structure like:

foo/
  bar/
    baz/
      qux/
        file.txt

The browser's file input gives you a flat list of files with relative paths. The client iterates over each file and makes an upload request (either POST or TUS) with the full destination path.

With skip=true, every single file and folder would hit the server, and the server checks if the destination already exists before writing. This means:

If bar/ doesn't exist on the server at all, then none of the nested files can possibly conflict. Yet the client would still:

• Send foo/bar/baz/qux/file.txt with skip=true
• Server checks existence → doesn't exist → writes it

This is fine for correctness (it works), but it's wasteful when you could short-circuit: if a parent directory doesn't exist, you know nothing inside it conflicts, so you could skip the per-file existence check and just upload everything directly.

This a big problem for our use case where hundreds or thousands of nested folders are uploaded.

If it is not to much of a burden, could you have a look to @geourjoa draft PR #5884

It implements a tree structure and a recursive function over this tree so it does not check for subfolders if it discovers that a parent does not exist on the server.

Also, it adds a "Resume previous transfert" that ignores existing files, except if they are smaller on the server. Indeed, if a big transfert is abruptly interrupter, some files will be partially uploaded and smaller on the server than they should be.

I'm not sure but it seems that Anthony's code is more concise (no changes in the backend) and yet more efficient than this proposal. I might be mistaken here and it is not at all to trash talk this contribution that is very welcome :-)

Hi @daxid, I've been testing @geourjoa 's PR and I think it's excellent. I find it a better implementation than this one in terms of speed, since it's not necessary to upload all the files if you select "Skip All" or the new "Resume previous transfer" option you've implemented. I've been testing it and haven't found any bugs so far. Just a couple of notes.

It would be good if, before displaying the conflict resolution modal, instead of making multiple requests for each directory and subdirectory, a single request were made to return the information for all of them (this would make displaying the modal a bit faster). I can work on this while it's still a draft.

And the other thing is basically a minor issue: the tooltip that appears in the "Resume previous transfer" option is great, but in the mobile version, its content is difficult to see (I've shown it by long-pressing the button because if I tap it, the "Resume previous transfer" option is selected). Adding the modifier @click.stop="() => {}" would work.

Otherwise, it's great; I think the implementation is solid.

Tank you @ArielLeyva this is great news.

Anthony will complete his PR and add your suggestions next week. We will probably have a couple of other PR on the way :-)

Go Filebrowser !

Hi @ArielLeyva @daxid

I just pushed new code in my PR :

• Solve a regression (when uploading a single file from UI not by drag and drop)
• Clean some useless log
• include your fix for the tooltip (thanks !)
• I revert a commit from fix: Fix docker compose deployment #5878

Have you work on a single fetch ?

I'm not so sure if its worth to implement it. The PR will be bigger, more complex to review. We have all tested a lot the current implementation and we are confident on it. And last but not least it, someone must do it. 😆

What's your sentiment on it ?

EDIT : Claude has done the fetchAll impl for me, I can start testing !

EDIT 2 : So far no issue, so I make my PR ready to review #5884

Hi @ArielLeyva @daxid

I just pushed new code in my PR :

• Solve a regression (when uploading a single file from UI not by drag and drop)
• Clean some useless log
• include your fix for the tooltip (thanks !)
• I revert a commit from fix: Fix docker compose deployment #5878

Have you work on a single fetch ?

I'm not so sure if its worth to implement it. The PR will be bigger, more complex to review. We have all tested a lot the current implementation and we are confident on it. And last but not least it, someone must do it. 😆

What's your sentiment on it ?

EDIT : Claude has done the fetchAll impl for me, I can start testing !

EDIT 2 : So far no issue, so I make my PR ready to review #5884

Excellent, @geourjoa, excellent implementation. I'll take a look and test it out. Regarding the single request improvement, that can be addressed in a future pull request once the current one is approved, keeping the review process simple.

I'll wait until you decide whether this PR or #5884 should be merged.