Linux permissions and owner being preserved with cp

Question

I am trying to set an app's config.assets.prefix, to /api/assets. Stylesheet & javascript links work fine, as well as rails image helpers.

However the font-url and image-url sass helpers are still using /assets instead of /api/assets.

The fonts & images are available at both paths, but I need the path to be /api/assets because the app is one of several living behind a Cloudfront distribution, and the behaviour uses the api path prefix to direct requests to the correct origin.

Why are font-url and image-url not respecting config.assets.prefix?

(app is still on Rails 4.2.x)

Solution 1

I don't get a prompt to overwrite. Why not?

Because you're supposed to know what you're doing. Especially as root, you can overwrite pretty much anything, so pay attention to that.

Use the -i option for cp to get a prompt before overwriting existing files. If you always want to be reminded of this, consider creating an alias for cp to cp -i.

The permissions are unchanged. But if […] file someFile does not exist it is owned by root and not user. Why?

Because the file you're copying to is already existing. It's not deleted and re-written. It's still owned by user.

However, check cp's -p option. It will preserve the attributes of the source file, namely the mode, ownership and timestamps. Otherwise, the mode and ownership attributes of the target file will stay (except for the timestamps which will indicate a modification).

If there's no target file, obviously the attributes of the source file need to be copied, since they can't be inherited from a target file. You'll basically just create a new file, and in this case it's owned by root.

Solution 2

1) cp will not prompt for overwrite unless the -i argument is used, this has been the default behavior since the first unix

2)from wikipedia : The overwriting of a file to an existing file is performed by opening the existing file in update mode, thereby preserving the files inode, which requires write access and results in the target file retaining the permissions it had originally.

Comments

[Daniel Andersson]

Just a comment on using aliases adding -ito cp/rm: it can be a problem if one gets used to this, and suddenly finds oneself on a system where these non-standard aliases are not set. It is good to not make a habit out of expecting them. "Default is almost always better", as I apparently said just now :-) .

[slhck]

Absolutely. If you're root you should be aware of that and it's not the first time I've seen someone overwrite important system files being too eager while copying.