Pre-create hook - filename needed

Morning all,

I would like to use the pre-create hook to check if the file being uploaded is already present, so I can avoid uploading it again. To do this, I need to get the filename, but it doesn’t seem to have any metadata available.

When I echo out the environment variables available in the pre-create hook, I get the following:
TUS_OFFSET=0
HOSTNAME=7f1256b75b52
SHLVL=1
HOME=/home/tusd
TUS_SIZE=1050921
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/srv/tusd-hooks
TUS_ID=

post-check it is available but then it has done the upload and i want to avoid that
If anyone can help me retrieve the filename or provide guidance on accessing the necessary metadata in the pre-create hook, it would be greatly appreciated.

Thank you!

The upload metadata is not available as an environment variable, but only via an JSON object that is provided via stdin (as most of the information about the upload and request). Please see Customization via hooks | tusd documentation and Customization via hooks | tusd documentation for more details

thank you for the quick repsonse. i got that working so i can see the filename

if i find it is a dulipicate , how to do i exit so it doesn’t attempt to upload the file? and go onto the next file

If you detect a duplicate file, you can reject the creation of the duplicate upload by setting RejectUpload to true. Have a look at this example: Customization via hooks | tusd documentation

Hi, thank you again for your quick responce

I’m using the pre-create hook script in tusd to check if a file has already been uploaded. If the file exists, I’m running the following code with in the sh script:
cat <<EOF
{
“HTTPResponse”: {
“StatusCode”: 400,
“Body”: “{"message":"File already exists: $DEST_FILE"}”,
“Header”: {
“Content-Type”: “application/json”
}
},
“RejectUpload”: true
}
EOF

This logs the following messages:

The script tries 5 times and then fails. I would like it to move on to the next file after encountering an existing file, rather than retrying.

Do you have any suggestions on how to achieve this? I want the script to continue processing the next file if it finds that a file already exists, without retrying multiple times.

Thank you for your help!

Hi Marius
As per our requirements, we need to prevent users from uploading duplicate files . To achieve this, I implemented a pre-create hook script that checks if the file already exists before allowing the upload to proceed. If a duplicate file is detected, the script constructs a response with a status code of 400 and a message indicating that the file already exists.

echo “{"RejectUpload": true, "HTTPResponse": {"StatusCode": 400, "Body": "File already exists: $dir/$FILENAME"}}”

logs
2024/06/10 05:52:45.151755 level=INFO event=RequestIncoming method=POST path=“” requestId=“”
2024/06/10 05:52:45.151807 level=DEBUG event=HookInvocationStart type=pre-create id=“”
2024/06/10 05:52:45.293724 level=DEBUG event=HookInvocationFinish type=pre-create id=“”
2024/06/10 05:52:45.294417 level=INFO event=ResponseOutgoing method=POST path=“” requestId=“” status=400 body=“File already exists: /srv/tusd-data/data/Administrator/tef/christmas.pub”

However, I noticed that when the script detects a duplicate file, it sends the response multiple times x5, then resulting in a failure on the client side. This behavior is not ideal, as we want to gracefully handle the situation without causing the client to fail.

Could you please advise on the best approach to we ensure that the client does not fail when a duplicate file is detected, but instead continues to the next upload attempt?

Your insights and guidance on this matter would be greatly appreciated

This is not correct. The hook does not send the response multiple times, but instead the client retries four times after it received the first 400 response. For each retry the pre-create is executed again, returning another 400, yielding this result.

You need to configure the client to detect those 400 responses and stop retrying when the response indicates that a duplicate file has been detected. The exact configuration steps depend on your client, but for tus-js-client you can use the onShouldRetry and onError callbacks. The passed error objects contain a reference to the last response from the server, which you can access to get the response body. In the end, you want to skip to the next upload if the duplicate file error is seen. But this logic has to be implemented on your own since tus client only upload individual files and not collections.

I hope this helps.

Hi Marius,
thank you for the pointers, i have now got that working

Best regards

Chris

1 Like

Handling Duplicate File Uploads with Custom Error Code 454 in Uppy

I’ve implemented the code to prevent duplicate files from being uploaded by returning a custom error code 454. This part works fine, and the error is correctly detected.

However, the issue I’m facing is with how this error is displayed in the console. Currently, it appears as a red error message in the uppy control, which isn’t ideal since I want to handle this specific error (454) as a successful upload. Here is the console output I’m getting:

Failed to load resource: the server responded with a status of 454 (status code 454)
uppy-index.html?user=Administrator:74 Duplicate file detected, marking as complete.

console output:
/files/:1

Failed to load resource: the server responded with a status of 454 (status code 454)
uppy-index.html?user=Administrator:58 Duplicate file detected, not retrying.
onShouldRetry @ uppy-index.html?user=Administrator:58
loggers.js:13 [Uppy] [14:18:40] xxxxxx.pdf tus: unexpected response while creating upload, originated from request (method: POST, url: xxxxxnet/files/, response code: 454, response text: File already exists: xxxxxxx.pdf, request id: n/a)

What I’m Trying to Achieve

  • I want the uppy control to appear as a green success message, complete instead of a red error retry

Glad to hear that you were able to work out the server-side implementation. Your question is now more about Uppy than tus, so I would recommend you to ask this question in the Uppy section of this forum and in Uppy’s GitHub repo directly.