Updating a paste creates new paste instead.

[rafasc]

Updating a paste doesn't seem to be working. It returns a new paste url with different short and long urls.

The old paste urls return status: not found upon request.

$ seq 2 10 | curl -F c=@- https://ptpb.pw
date: 2018-04-10T13:15:33.109673+00:00
digest: 41d913f49860ff7ed257f4bec40c567c4b97aea4
long: AEHZE_SYYP9-0lf0vsQMVnxLl66k
short: l66k
size: 19
status: created
url: https://ptpb.pw/l66k
uuid: b88d6fea-9492-44a2-81ea-b71450af4c33

$ curl https://ptpb.pw/l66k
2
3
4
5
6
7
8
9
10

$ seq 2 5 | curl -X PUT -F c=@- https://ptpb.pw/b88d6fea-9492-44a2-81ea-b71450af4c33
date: 2018-04-10T13:15:33.109000+00:00
digest: 6d006080d7cfc392a854c1d63a2207f2c8ab2264
long: AG0AYIDXz8OSqFTB1joiB_LIqyJk
short: qyJk
size: 8
status: updated
url: https://ptpb.pw/qyJk

[buhman]

TLDR: If you want a persistent URL, you should use a custom label, also called "vanity url".

https://ptpb.pw/#vanity-pastes

new paste url

Yes, this is how updating pastes works--the underlying paste content was indeed updated in-place, but this also changes the digest, which in turn changes the short and long urls, which are derived from digest (internally these are actually just view/route transformations of digest, and aren't modeled at all the storage layer).

paste urls return status: not found

Due to the paste content being updated in-place, and that paste's digest being updated accordingly, there is indeed no longer a paste with that url.

Admittedly, while from an implementation perspective this behavior makes complete sense, and results in a very minimal data model, from a user perspective I understand the confusion.

[rafasc]

Thanks for clarifying this. I made the wrong assumption and was trying to fix small mistakes on pastes that were are already posted.

What's the advantage from a user perspective to use that over something like: https://ptpb.pw/~$(base64 /dev/urandom | head -c 8) ? Or would this be considered abuse of service?

[buhman]

https://ptpb.pw/~$(base64 /dev/urandom | head -c 8) Or would this be considered abuse of service?

I explicitly declare this as a valid way to use this feature.

Related, I'm aware some people (and worse, services like IRC bots) try make some intermediate-sized paste IDs like:

https://ptpb.pw/AAAA.qqqqqq

This is 100% invalid, because the qqqqqq portion is only used for mimetype calculation, and is not considered by the storage layer at all.

By contrast, using the label feature is the correct way to accomplish the above outcome.

---

What's the advantage from a user perspective to use that over something like:

The origin of this model came from something like:

"How do I know if the paste I want to download hasn't changed from the last time I tried to download it?"

Provided you ~unconditionally trust pb's implementation and operational integrity, but not necessarily the same level of unconditional trust in the paste's author, selecting a paste by long id robustly satisfies the implications of this question (or at least for as long as sha1 is considered unbroken, which currently is only arguably true).

This is also the origin of the ~ prefix; it symbolizes an "untrusted" user-defined ID.

Other than that, there is no advantage from a user perspective.