Infer destination object name for `pelican object put` to "directory" location

[aowen-uwmad]

Pelican Service:

• Client
• Plugin
• Registry
• Director
• Origin
• Cache
• Other (please give the detail)

Is your feature request related to a problem? Please describe.
When uploading (put-ing) to an existing namespace, users have built up the intuition that the object name at the destination is inferred by the object name at the source. That is, users expect

pelican object put ./aowen-uwmad_test.txt osdf:///<existing_namespace>

to have the same outcome as

pelican object put ./aowen-uwmad_test.txt osdf:///<existing_namespace>/aowen-uwmad_test.txt

This arises from such behavior of common unix commands such as mv, cp, and scp when an existing directory is provided as the destination.

Instead, the user receives an error like this:

ERROR[2026-01-05T12:31:53-06:00] Error when attempting to transfer object osdf:///<existing_namespace> for client 019b8f6e-0f40-711d-a992-3ab2693ab191: remote object already exists, upload aborted

The intuition built up by the user further confuses the point - they interpret the error to mean that the object they are trying to upload (aowen-uwmad_test.txt) already exists in the namespace (osdf:///<existing_namespace>/aowen-uwmad_test.txt), but any subsequent queries (pelican object ls, pelican object get) against that supposed object will fail.

Describe the solution you'd like
The command

pelican object put ./aowen-uwmad_test.txt osdf:///<existing_namespace>

has the same outcome as

pelican object put ./aowen-uwmad_test.txt osdf:///<existing_namespace>/aowen-uwmad_test.txt

Additional context

1. For downloads, the client already infers the object name if not provided at the destination. That is,

   pelican object get osdf:///<existing_namespace>/aowen-uwmad_test.txt ./
   

   behaves the same as

   pelican object get osdf:///<existing_namespace>/aowen-uwmad_test.txt ./aowen-uwmad_test.txt
   

   as expected.

2. If the current behavior is a policy decision (e.g., "users should not upload objects without being explicit about the name"), I'll counter that implicit naming is already used for --recursive or sync uploads anyways, so implementing this feature will not break a fundamental premise.

3. If there is no desire to implement this feature, then I recommend that, at the very least, the client handles the existing error and suggests to the user something like Did you mean to run "pelican object put aowen-uwmad_test.txt osdf:///<existing_namespace>/aowen-uwmad_test.txt"?.

[jhiemstrawisc]

@aowen-uwmad I have a question about what you view as "the expected behavior" in an edge case @patrickbrophy and I were just discussing.

Let's say there's a namespace /foo that is backed by a POSIX Origin, and the /foo namespace points at / in the filesystem for the sake of simplicity. If you do pelican object put my-file.txt /foo, you'd expected the POSIX filesystem to contain /my-file.txt, right?

Now let's say there's a subdirectory in the filesystem called /subdir that you want your object to live in. If you do pelican object put /foo/subdir, since /subdir isn't part of the namespace, the client has to decide "do I append my-file.txt to the path, or is subdir what the object should be called under the /foo namespace". The only real way to figure that out is for the client to first check /foo to see whether there's already a subdirectory called subdir there. If there is, we probably want the filesystem to contain /subdir/my-file.txt and if there isn't, then we want /subdir to be the object.

But what if there isn't already a subdirectory for the client to discover? How can we tell whether the user actually wants the client to create a subdirectory and append the object name, or whether the end of the path should become the object name?

We could go the route of treating a trailing / as semantically important, e.g. pelican object put /foo/subdir/ means we treat subdir like a directory while pelican object put /foo/subdir means we treat subdir as the object name, but I doubt that's going to lead to a positive user experience.

I also don't know how all this plays into the fact we often pretend "there are no files and directories in Pelican land, only object and collections."

Thoughts?

[aowen-uwmad]

First example: right.

The second example does depend on whether or not /subdir exists already, and it's nature.

• If /subdir exists and is a directory, then the put should end up with /foo/subdir/my-file.txt.
• If /subdir exists and is an object, then this counts as "overwriting an existing object" and should return an error as such.
• If /subdir does not exist, and there's no trailing slash, then the contents of my-file.txt are saved to an object with the address /foo/subdir.
• If /subdir does not exist, and there is a trailing slash, then that counts as "namespace not found", to match the similar behavior in cp/scp that returns a Not a directory error under the analogous case.