[GH-ISSUE #413] Upload if hash matches #223

New Issue

zhus · 2026-04-08T16:51:16+03:00

zhus commented

2026-04-08 16:51:16 +03:00

Originally created by @zareith on GitHub (Jul 13, 2024).
Original GitHub issue: https://github.com/sigoden/dufs/issues/413

Hello, thanks for creating and open sourcing dufs. This looks really useful.

Specific Demand Request

It would be very useful for me if we could have a way to upload file only if the current version matches a specific sha.

The idea is to build a web ui that fetches file from dufs, allows user to edit it and while uploading if the hash doesn't match what we had when receiving we ask user to resolve conflict first.

Implement Suggestion

Similar to how we can do the following for download:

curl http://127.0.0.1:5000/path-to-file?hash      # retrieve the sha256 hash of the file

We could support:

curl -T path-to-file http://127.0.0.1:5000/new-path/path-to-file?hash=prev-sha256

and the server fails with an error code if the file has been modified by another user, causing a hash mismatch.

Originally created by @zareith on GitHub (Jul 13, 2024). Original GitHub issue: https://github.com/sigoden/dufs/issues/413 Hello, thanks for creating and open sourcing dufs. This looks really useful. ## Specific ~~Demand~~ Request It would be very useful for me if we could have a way to upload file only if the current version matches a specific sha. The idea is to build a web ui that fetches file from dufs, allows user to edit it and while uploading if the hash doesn't match what we had when receiving we ask user to resolve conflict first. ## Implement Suggestion Similar to how we can do the following for download: ``` curl http://127.0.0.1:5000/path-to-file?hash # retrieve the sha256 hash of the file ``` We could support: ``` curl -T path-to-file http://127.0.0.1:5000/new-path/path-to-file?hash=prev-sha256 ``` and the server fails with an error code if the file has been modified by another user, causing a hash mismatch.

zhus closed this issue

2026-04-08 16:51:16 +03:00

zhus commented

2026-04-08 16:51:17 +03:00

@sigoden commented on GitHub (Jul 13, 2024):

This strategy does not solve the problem. This policy has a race condition that cannot be resolved.

Let me explain:

Assume ClientA and ClientB edit file1 at the same time

ClientA gets hash1 of file1
ClientB gets hash1 of file1
ClientB starts writing file1, hash of file1 still be hash1, read to write
ClientA starts writing file2, hash of file1 still be hash1, read to write
Ops, Two writing at the same time.

Using locks can solve such problems. However, dufs is stateless and doesn't support locks. If you need to support concurrent writes, consider software that provides locking mechanisms.

@sigoden commented on GitHub (Jul 13, 2024): This strategy does not solve the problem. This policy has a race condition that cannot be resolved. Let me explain: Assume ClientA and ClientB edit file1 at the same time ClientA gets hash1 of file1 ClientB gets hash1 of file1 ClientB starts writing file1, hash of file1 still be hash1, read to write ClientA starts writing file2, hash of file1 still be hash1, read to write Ops, Two writing at the same time. Using locks can solve such problems. However, dufs is stateless and doesn't support locks. If you need to support concurrent writes, consider software that provides locking mechanisms.

zhus referenced this issue

2026-04-08 16:53:17 +03:00

[PR #224] [MERGED] fix: auth logic #523

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sigoden/dufs#223