Bug 5279 - vfswrap_rename checks wrong status
Summary: vfswrap_rename checks wrong status
Status: RESOLVED FIXED
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: File Services (show other bugs)
Version: 3.0.28
Hardware: All All
: P3 normal
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-02-25 04:04 UTC by Max Matveev
Modified: 2008-02-25 06:02 UTC (History)
0 users

See Also:


Attachments

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.

Thanks,

Volker