Re: [PATCH] Fix 'git clean' failure on NFS.

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

 



On 06/18/2010 03:17 PM, Johannes Sixt wrote:
> Am 6/18/2010 13:07, schrieb Török Edwin:
>>  		else if (S_ISDIR(st.st_mode)) {
>> -			if (!remove_dir_recursively(path, only_empty))
>> +			if (!remove_dir_recursively(path, only_empty)) {
>> +				did_rm = 1;
>>  				continue; /* happy */
> 
> Is it possible that remove_dir_recursively exits with 0, but it actually
> did not remove the directory? That would result in an endless loop: it
> would have to re-enter remove_dir_recursively on the next iteration,
> return 0 again (without removing the directory), next iteration, etc.

Hmm, I think this could cause problems:
	if ((flag & REMOVE_DIR_KEEP_NESTED_GIT) &&
	    !resolve_gitlink_ref(path->buf, "HEAD", submodule_head))
		/* Do not descend and nuke a nested git work tree. */
		return 0;

What if we limit the amount of times you can loop?
The worst case is that you loop == number of files in the directory, if
you loop more times than we could break out early.

Or we can compare the number of files listed in one pass, and in
another. If they stay equal, we can break out (since we'd infloop), if
it is higher (new files added) or lower (successfully removed some) we
can keep looping.

How does that sound?

--Edwin
--
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]