Bug 5279 - vfswrap_rename checks wrong status
vfswrap_rename checks wrong status
Product: Samba 3.0
Classification: Unclassified
Component: File Services
All All
: P3 normal
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2008-02-25 04:04 UTC by Max Matveev
Modified: 2008-02-25 06:02 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Max Matveev 2008-02-25 04:04:19 UTC
modules/vfs_default.c has this:

    446         result = rename(oldname, newname);
    447         if (errno == EXDEV) {
    448                 /* Rename across filesystems needed. */
    449                 result = copy_reg(oldname, newname);
    450         }

Strictly speaking, errno DOES NOT need to be changed if rename(2) succeeds.
I have at least one example - Irix which does not change errno unless
there is a real reason to do so. If errno was set to EXDEV from a previous
system call, then smbd will fall back to byte copy in copy_reg while it 
really should not.

I think the line 447 above should look something like

   if ((result < 0) && (errno == EXDEV)) { 

Also, in copy_reg, if it returns an error, should it clean up the destination?
Right now it would leave a file behind if, for example, chmod(2) fails after
chown "gave away" the newly created file.
Comment 1 Volker Lendecke 2008-02-25 06:02:39 UTC
Pushed the obvious rename fix.

If you feel like it, can you fix the copy_reg case and provide a patch? To me this looks very reasonable.