Well, unfortuantely, in a symlinked FS that is not a simple operation. The
symlink refers to a data file and the data file has an xattr that records
its symlink name. All of that has to change to successfully overwrite the
symlink. Merely removing the symlink test would really screw things up for
many people. I guess that's why we forbid renaming on top of an existing
file. I don't have a problem of restricting destructive renames to simple
file systems as long as that's OK with you.

Andy

On Thu, 1 Mar 2018, Gerardo GANIS wrote:

> gganis commented on this pull request.
>
>
>
>> //
> -#if 0
> - retc2 = lstat(local_path_New, &statbuff);
> - if (!retc2) return -EEXIST;
> -#endif
> + if (!(retc2 = lstat(local_path_New, &statbuff)))
> + { if (remotefs || (statbuff.st_mode & S_IFMT) == S_IFLNK) return -EEXIST;
> + }
>
> The symlink part comes from your original comment. In my case I am mostly interested to local file, no symlinks. However, I see that the man page of rename says that
>
> if newpath refers to a symbolic link, the link will be overwritten
>
> So I suggest that we only leave the check on 'remotefs'. What do you think?
>
> --
> You are receiving this because you commented.
> Reply to this email directly or view it on GitHub:
> https://github.com/xrootd/xrootd/pull/660#discussion_r171563928


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/xrootd/xrootd","title":"xrootd/xrootd","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/xrootd/xrootd"}},"updates":{"snippets":[{"icon":"PERSON","message":"@abh3 in #660: Well, unfortuantely, in a symlinked FS that is not a simple operation. The \nsymlink refers to a data file and the data file has an xattr that records \nits symlink name. All of that has to change to successfully overwrite the \nsymlink. Merely removing the symlink test would really screw things up for \nmany people. I guess that's why we forbid renaming on top of an existing \nfile. I don't have a problem of restricting destructive renames to simple \nfile systems as long as that's OK with you.\n\nAndy\n\nOn Thu, 1 Mar 2018, Gerardo GANIS wrote:\n\n\u003e gganis commented on this pull request.\n\u003e\n\u003e\n\u003e\n\u003e\u003e //\n\u003e -#if 0\n\u003e - retc2 = lstat(local_path_New, \u0026statbuff);\n\u003e - if (!retc2) return -EEXIST;\n\u003e -#endif\n\u003e + if (!(retc2 = lstat(local_path_New, \u0026statbuff)))\n\u003e + { if (remotefs || (statbuff.st_mode \u0026 S_IFMT) == S_IFLNK) return -EEXIST;\n\u003e + }\n\u003e\n\u003e The symlink part comes from your original comment. In my case I am mostly interested to local file, no symlinks. However, I see that the man page of rename says that\n\u003e\n\u003e if newpath refers to a symbolic link, the link will be overwritten\n\u003e\n\u003e So I suggest that we only leave the check on 'remotefs'. What do you think?\n\u003e\n\u003e -- \n\u003e You are receiving this because you commented.\n\u003e Reply to this email directly or view it on GitHub:\n\u003e https://github.com/xrootd/xrootd/pull/660#discussion_r171563928\n"}],"action":{"name":"View Pull Request","url":"https://github.com/xrootd/xrootd/pull/660#issuecomment-369601610"}}}

Use REPLY-ALL to reply to list

To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1