Double `touch` errors about mountpoint-s3 HOT 2 CLOSED

This isn't ideal, but it is our intended behavior. Our thinking was that we don't want to lie about touch successfully persisting the modification time update back to S3, which it can't do. It quickly becomes a slippery slope of "what mutations are we allowed to lie about" so we decided to just draw a bright line. (It's mentioned tangentially in #391, which is when we made touch work properly on new files because there we actually can persist the update.)

I'm hoping it's not something that's going to actively block you, but if it is please let us know!

from mountpoint-s3.

Thanks for the response - the reasoning makes sense.

It does seem the modification date is immutable. I believe you could replicate touch by writing empty-file if it doesn't exist, or copying the file to itself if it does. I'm not sure if the posix spec gives you enough details to know to do this.

Anyway, it's not a huge deal. I build our own mountpoint binary anyway, so I just patch it to no-op touches when the file exists (shouldn't be upstreamed, but fine for my use-case). This is the only patch that I carry but it doesn't cause much pain.

Thanks as always for the response.

from mountpoint-s3.