Re: [PATCH 2/2] Use is_pseudo_dir_name everywhere

[Alexander Potashev <aspotashev@gmail.com>]

On 00:33 Fri 09 Jan     , Junio C Hamano wrote:
> Johannes Sixt <j.sixt@viscovery.net> writes:
> 
> > Johannes Sixt schrieb:
> >> Alexander Potashev schrieb:
> >>> -		if ((ent->d_name[0] == '.') &&
> >>> -		    (ent->d_name[1] == 0 ||
> >>> -		     ((ent->d_name[1] == '.') && (ent->d_name[2] == 0))))
> >>> +		if (is_pseudo_dir_name(ent->d_name))
> >> 
> >> Nit-pick: When I read the resulting code, then I will have to look up that
> >>   is_pseudo_dir_name() indeed only checks for "." and "..". But if it were
> >> named is_dot_or_dotdot(), then I would have to do that.
> >
> > ... then I would *not* have to do that, of course.
> 
> I think the unstated motivation of this choice of the name is to keep the
> door open to include lost+found and friends to the repertoire, and perhaps
> to have an isolated place for customization for non-POSIX platforms and
> for local conventions.  It is more like is_uninteresting_dirent_name().

I didn't think over the support of 'lost+found'. But the name like
is_uninteresting_dirent_name is more flexible, indeed. I prefer a bit
shorter name, 'is_dummy_dirent_name'.

But if you're going to support 'lost+found's, remember that a Git
repository might have its own 'lost+found' directory. It's a bit crazy,
but it's possible:
	---
	 lost+found/file |    1 +
	 1 files changed, 1 insertions(+), 0 deletions(-)
	 create mode 100644 lost+found/file

	diff --git a/lost+found/file b/lost+found/file
	new file mode 100644
	index 0000000..190a180
	--- /dev/null
	+++ b/lost+found/file
	@@ -0,0 +1 @@
	+123
	-- 

Git shouldn't allow to clone at least repositories that have lost+found
directory into a directory with already existing lost+found (neither
it's a ordinary directory created using 'mkdir' nor it's an ext2's
property)

We should probably forbid cloning to a directory with lost+found,
because a 'lost+found' may appear after pulling from somebody and the
user won't be able to resolve this anyhow.

> 
> As long as this function is used only to detect and skip "uninteresting"
> dirent, I think that is not a bad direction.
> 
> On the other hand, I am a bit worried about is_empty_dir() abused outside
> its intended purpose to say "this directory does not have anything
> interesting".  E.g. "Oh, it's empty so we can nuke it":

I propose to rename it (if it's really necessary) to is_clean_dir, which
means "There's no old crap here, we can safely clone".

> 
> 	if (is_empty_dir(dir))
>         	rmdir(dir);
> 
> even though the current callers do not do something crazy like this (the
> usual order we do things is rmdir() and then check for errors).

I think, it's rather early to send [PATCHES v2] (with updated function
names), will wait for your comments.