[Bug]: Public share with write only access allows overwriting of files without user knowledge

[suiluj]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration issue.
• This issue is not already reported on Github (I've searched it).

Bug description

Hello,

while trying out different options of user account created web ui link shares I noticed that uploaded files get overwritten without when choosing the write share option. (file drop without being able to read/see uploaded files in a share).

This behaviour is different when choosing read/write as share option. Then you get a warning popup that the name of the new uploaded files is already existing.

I would prefer options to adjust this behaviour so users cannot delete or change files by mistake or in bad faith

Steps to reproduce

1. create a link share with write only access
2. upload a test file, lets say a text file test.txt with the content 1
3. upload a another files called test.txt with the content 0
4. there will be no warning or anything but the available file will contain the content from the last uploaded version (0 in this case)

Expected behavior

In case a user with the upload link tries to upload a file (or folder with subfolders and files) and the path already exists this should not overwrite the content of previously existing files.

Instead there should be options:

Option 1

• sftpgo should add a suffix (counter or timestamp) to the file paths
• in case of a folder upload this suffix could be part of the main uploaded folder only (instead of each individual file)

Option 2

• there should be a notification similar to a link share with write and read permissions that warns the user that the file already exist
• and then the user should have options like
  • skip already existing paths
  • overwrite existing
  • add suffix as describe in Option 1

SFTPGo version

2.7.1 1312348

Data provider

local file paths

Installation method

Community Docker image

Configuration

not relevant

Relevant log output

What are you using SFTPGo for?

Private user, home usecase (home backup/VPS)

Additional info

I would not describe this a bug but more as a suggestion for a behaviour I would prefer/expect from the file drop/write only upload share link feature.

[drakkan]

Hi, thanks for the detailed report.

You're right that a write-only ("drop") share intentionally hides existing files, so the client can't warn you about a name clash the way a
read/write share does. We don't want to surface an "already exists" prompt there, since that would leak the existence of files the uploader isn't allowed to see.

A couple of options to get the behavior you want today:

• Remove the overwrite permission from the user backing the share. Uploads to an existing path will then be rejected. It's the simplest lever, but not very convenient, the upload just fails and the file is lost rather than being kept under a new name.
• Better: use a pre-upload event rule to move the existing file aside on collision. Define a rule on the pre-upload filesystem event, scoped to the share protocol, with a minimum-size condition so it only triggers when a file is already present, and a filesystem rename action that renames the existing file to a unique name (e.g. appending a timestamp/uuid) before the new upload is written. The result: nothing is overwritten, the previous version is preserved, and the uploader still just sees a successful upload.

We may also evaluate adding a dedicated checkbox on the share in the future to make this simpler.