sftp: Couldn't rename file1 file2 -- why not?

[abc_18]

HP-UX 11.23
If I ftp into a machine with two files:
file1 ----- perms: 666
file1.new -- perms: 666

and try this:

sftp> rename file1.new file1

I get this wierd error:

Couldn't rename file "/home/fred/file1.new" to "/home/fred/file1": Failure

The perms on both files are 666, so one should be allowed to overwrite the other. If I do this:

sftp> rm file1

then the rename operation will work. But I don't want to "rm" the file first - I want to
do everything with just one command, "rename", so that the operation will be atomic, ie, I'll be guarenteed I won't be in a situation where the internet connection drops b/n the "rm" and the "rename" command.

I've googled,and come up empty. The src for sftp has some obscure reference to SSH2_FX_FAILURE but it wasn't at all clear what it was for.

The ssh config files don't seem to have any options governing the "rename" semantics.

Any suggestions?

Thanks in advance!

[abc_18]

Small typo: I meant to write "If I sftp into a machine...", not "if I ftp into a machine..."

[Dennis Handly]

>The src for sftp has some obscure

If you have the source, can you look at what the rename command does?

>But I don't want to "rm" the file first

You may be stuck with that. I'm not even sure if ftp will do that.

>I want to do everything with just one command, "rename", so that the operation will be atomic

Unfortunately it can't really be atomic since link(2) will not allow a rename with an existing file of the same name, EEXIST.

>I'll be guaranteed I won't be in a situation where the Internet connection drops b/n the "rm" and the "rename" command.

Well, having the command built into ftp/sftp would get pretty close. Blocking signals between the two would help even more.

[Steven E. Protter]

Shalom,

Check the umask on the receiving server, you may think its 666 but maybe its not.

Also the ssh configuration on the server in sshd_config may be preventing you from suceeding in this operation.

SEP

[abc_18]

To answer a few questions:

This operation works just fine with regular ftp.

I realize that it's not truly atomic, but it's a lot closer than using two separate cmds.

I've checked sshd_config, and there are no parms in there that seem even remotely related to this behavior.

The sshd's umask wouldn't be relevant would it? After all, file1.new and file1 already exist...

Thanks in advance for any other suggestions

[Bill Hassell]

Very important concept in Unix: the existence of a file has NOTHING to do with the file's permissions. The file's permissions only protect the contents. But the directory where the file resides controls the file's existence. You cannot create or rename or remove a file without having write permission in the directory. A rename requires write permission to update the directory.

By the way, 666 is a poor choice for permission because anyone can corrupt your file. 664 or 644 if everyone needs to reade the file, 640 if only group users should read the file.

[Steve Post]

Like Bill suggested, check the permissions on the directory where these 2 files reside.

Check the sshd_config file.

Don't discount permissions because it works for ftp and not for sftp. Perhaps you use a different login name for ftp? And that ftp userlogin has permission to modify the contents of this directory?

[abc_18]

I tried making $HOME be 777, but it didn't help. Same error.

In case you want to try on your own system,
here's an explicit step-by-step on how to
reproduce this wierdness (where sftp won't let me rename a file to overwrite an existing file):
- abc: problem: sftp won't let me rename a file to
overwrite an existing file:

mustang(fred) 107> pwd
/home/fred

mustang(fred) 108> ll -d .
drwxr-xr-x 4 fred itrc 1024 Jul 9 10:58 ./

- in fact, it won't even work if my $HOME is 777:

mustang(fred) 109> chmod 777 .

mustang(fred) 110> ll -d .
drwxrwxrwx 4 fred itrc 1024 Jul 9 10:58 ./


mustang(fred) 115> cp /etc/checklist catalog
mustang(fred) 116> cp /etc/copyright catalog.new
mustang(fred) 117> chmod 666 catalog*
mustang(fred) 118> ll catal*
-rw-rw-rw- 1 fred users 890 Jul 9 12:59 catalog
-rw-rw-rw- 1 fred users 1152 Jul 9 13:00 catalog.new


mustang(fred) 120> sftp mustang
Connecting to mustang...
fred@mustang's password:

sftp> ls -l cata*
-rw-rw-rw- 0 15443 20 890 Jul 9 12:59 catalog
-rw-rw-rw- 0 15443 20 1152 Jul 9 13:00 catalog.new


- abc: still won't let me rename a file if an existing file
has the same name:

sftp> rename catalog.new catalog
Couldn't rename file "/home/fred/catalog.new" to "/home/fred/catalog": F
ailure

- abc: but if I remove that file, *then* it will let me:


sftp> rm catalog
Removing /home/fred/catalog

sftp> rename catalog.new catalog

- abc: it worked :-) Notice that "catalog" now has the file size (1152)
of the file "catalog.new"":

sftp> ls -l cata*
-rw-rw-rw- 0 15443 20 1152 Jul 9 13:01 catalog

sftp> quit

----
Any other ideas on how to get this to work?
Thanks in advance...

[A. Clay Stephenson]

This is almost certainly a function of application design that simply says if a target file exists then you are not allowed to link. You seem to be expecting sftp to behave as the UNIX mv command does but sftp ain't mv.

[A. Clay Stephenson · Accepted solution]

I just examined the source code for the sftp-server process_rename() function and it works exactly as I expected. It calls link() which will fail if the target path exists. You could, of course, download the source from www.openssh.org and get it to do what you want using the rename() system call rather than link().

[abc_18]

.