/*
* CDDL HEADER START
*
* The contents of this file are subject to the terms of the
* Common Development and Distribution License, Version 1.0 only
* (the "License"). You may not use this file except in compliance
* with the License.
*
* You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
* See the License for the specific language governing permissions
* and limitations under the License.
*
* When distributing Covered Code, include this CDDL HEADER in each
* file and include the License file at usr/src/OPENSOLARIS.LICENSE.
* If applicable, add the following below this CDDL HEADER, with the
* fields enclosed by brackets "[]" replaced with your own identifying
* information: Portions Copyright [yyyy] [name of copyright owner]
*
* CDDL HEADER END
*/
/*
* Copyright (c) 1995 Sun Microsystems, Inc. All Rights Reserved
*
* module:
* rename.c
*
* purpose:
* routines to determine whether or not any renames have taken place
* and note them (for reconciliation) if we find any
*
* contents:
* find_renames . look for files that have been renamed
* find_oldname . (static) find the file we were renamed from
* note_rename .. (static) note the rename for subsequent reconciliation
*
* notes:
* the reason renames warrant special attention is because the tree
* we have constructed is name based, and a directory rename can
* appear as zillions of changes. We attempt to find and deal with
* renames prior to doing the difference analysis.
*
* The only case we deal with here is simple renames. If new links
* have been created beneath other directories (i.e. a file has been
* moved from one directory to another), the generalized link finding
* stuff will deal with it.
*
* This is still under construction, and to completely deal with
* directory renames may require some non-trivial tree restructuring.
* There is a whole design note on this subject. In the mean time,
* we still detect file renames, so that the user will see them
* reported as "mv"s rather than as "ln"s and "rm"s. Until directory
* renames are fully implemented, they will instead be handled as
* mkdirs, massive links and unlinks, and rmdirs.
*/
#ident "%W% %E% SMI"
#include <stdio.h>
#include "filesync.h"
#include "database.h"
/* local routines */
static errmask_t
/*
* routine:
* find_renames
*
* purpose:
* recursively perform rename analysis on a directory
*
* parameters:
* file node for the suspected directory
*
* returns:
* error mask
*
* note:
* the basic algorithm here is to search every directory
* for files that have been newly created on one side,
* and then look to see if they correspond to an identical
* file that has been newly deleted on the same side.
*/
/* if this isn't a directory, there is nothing to analyze */
return (0);
/* look for any files under this directory that may have been renamed */
/* a rename must be a file that is new on only one side */
if (rp)
}
}
/* recursively examine all my children */
}
return (errs);
}
/*
* routine:
* find_oldname
*
* purpose:
* to search for an old name for a newly discovered file
*
* parameters:
* file node for the containing directory
* file node for the new file
* which side the rename is believed to have happened on
*
* returns:
* pointer to likely previous file
* 0 no candidate found
*
* note:
* this routine only deals with simple renames within a single
* directory.
*/
/* figure out what we're looking for */
/*
* search the same directory for any entry that might describe
* the previous name of the new file.
*/
/* previous name on changed side must no longer exist */
continue;
/* previous name on the other side must still exist */
continue;
/* it must describe the same inode as the new file */
continue; /* must be same type */
continue; /* must be same inode # */
continue; /* must be same major # */
continue; /* must be same minor # */
/*
* occasionally a prompt delete and create can reuse the
* same i-node in the same directory. What we really
* want is generation, but that isn't available just
* yet, so our poor-man's approximation is the size.
* There is little point in checking ownership and
* modes, since the fact that it is in the same
* directory strongly suggests that it is the same
* user who is doing the deleting and creating.
*/
continue;
/* looks like we found a match */
return (fp);
}
/* no joy */
return (0);
}
/*
* routine:
* note_rename
*
* purpose:
* to record a discovered rename, so that the reconciliation
* phase will deal with it as a rename rather than as link
* followed by an unlink.
*
* parameters:
* file node for the containing directory
* file node for the new file
* file node for the old file
* which side the rename is believed to have happened on
*
* returns:
* error mask
*/
static errmask_t
{
int dir;
/* FIX: we don't deal with directory renames yet */
if (dir)
return (0);
/* note that a rename has taken place */
} else {
}
/* put a link to the old name in the new name */
/* for most files, there is nothing else we have to do */
if (!dir)
return (errs);
/*
* FIX ... someday we are going to have to merge the old and
* new children into a single tree, but there are
* horrendous backout problems if we are unable to
* do the mvdir, so I have postponed this feature.
*/
return (errs);
}