Re: Behavior of git rm

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeff King <peff@xxxxxxxx> writes:

> Of the two situations, I think the first one is less likely to be
> destructive (noticing that a file is already gone via ENOTDIR), as we
> are only proceeding with the index deletion, and we end up not touching
> the filesystem at all.

Nice to see sound reasoning.

>
> diff --git a/builtin/rm.c b/builtin/rm.c
> index dabfcf6..7b91d52 100644
> --- a/builtin/rm.c
> +++ b/builtin/rm.c
> @@ -110,7 +110,7 @@ static int check_local_mod(unsigned char *head, int index_only)
>  		ce = active_cache[pos];
>  
>  		if (lstat(ce->name, &st) < 0) {
> -			if (errno != ENOENT)
> +			if (errno != ENOENT && errno != ENOTDIR)

OK.  We may be running lstat() on D/F but there may be D that is not
a directory.  If it is a file, we get ENOTDIR.

By the way, if D is a dangling symlink, we get ENOENT; in such a
case, we report "rm 'D/F'" on the output and remove the index entry.

	$ rm -f .git/index && rm -fr D E
	$ mkdir D && >D/F && git add D && rm -fr D
        $ ln -s erewhon D && git rm D/F && git ls-files
        rm 'D/F'

Also if D is a symlink that point at a directory E, "git rm" does
something interesting.

(1) Perhaps we want a complaint in this case.

	$ rm -f .git/index && rm -fr D E
	$ mkdir D && >D/F && git add D && rm -fr D
	$ mkdir E && ln -s E D && git rm D/F

(2) Perhaps we want to make sure D/F is not beyond a symlink in this
    case.

	$ rm -f .git/index && rm -fr D E
	$ mkdir D && >D/F && git add D && rm -fr D
	$ mkdir E && ln -s E D && date >E/F && git rm D/F


	$ git rm -f D/F

> diff --git a/dir.c b/dir.c
> index 57394e4..f9e7355 100644
> --- a/dir.c
> +++ b/dir.c
> @@ -1603,7 +1603,7 @@ int remove_path(const char *name)
>  {
>  	char *slash;
>  
> -	if (unlink(name) && errno != ENOENT)
> +	if (unlink(name) && errno != ENOENT && errno != ENOTDIR)
>  		return -1;

Ditto.

>  
>  	slash = strrchr(name, '/');
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]