[9fans] ftpfs ahould not expose "." and ".." directories

[9fans] ftpfs ahould not expose "." and ".." directories

[eekee57]

Hi all. I had a problem trying to use dircp with ftpfs the other day,
and made a little patch to ftpfs to fix it.

The Problem: Many operating systems expose the psuedo-directories "."
and ".." in their directory structure, and understandably many FTP
servers running on those operating systems pass the pseudo-directories
on to their clients. Plan 9 does does not expose those psuedo-
directories, so Plan 9's tar program does not treat them specially.
ftpfs does not hide the pseudo-directories, so Plan 9 tar (and thus
the dircp script too) will fail on encountering them, getting into a
loop until the sequence of directory/../directory/../directory/../
etc. just gets too long. Note that tar may fail to pack all files in
the tree before failing.

My Fix: I have added a little code to ftpfs to hide the "." and ".."
directories when the server operating system is detected as UNIX,
Windows-NT, or Plan 9. I included the Plan 9 case because these 3
operating systems are lumped together in the code, and the heuristics
to tell them apart by detail may be fooled by some server which
happens to list files in a similar manner.

My code consists of 5 near-identical if statements in the function
that parses each line returned from an ftp LIST or NLST command:

664a665,666
> 			if(!strncmp(".", field[7], 2) || !strncmp("..", field[7], 3))
> 				return nil;
675a678,679
> 			if(!strncmp(".", field[8], 2) || !strncmp("..", field[8], 3))
> 				return nil;
686a691,692
> 			if(!strncmp(".", field[9], 2) || !strncmp("..", field[9], 3))
> 				return nil;
697a704,705
> 			if(!strncmp(".", field[3], 2) || !strncmp("..", field[3], 3))
> 				return nil;
712a721,722
> 			if(!strncmp(".", field[0], 2) || !strncmp("..", field[0], 3))
> 				return nil;

return nil results in ftpfs ignoring that line of the listing
entirely. strncmp() may not be the best function as it is supposed to
compare lexicographically. I'm not sure whether a "lexicographic"
comparison is appropriate, but I think Plan 9 strncmp is currently a
simple byte-by-byte comparison.

Patched /sys/src/cmd/ip/ftpfs/proto.c file:
http://eekee.org.uk/plan9/ftpfs..patch/proto.c

Also FYC are an ed script and a context diff:
http://eekee.org.uk/plan9/ftpfs..patch/diff.ed
http://eekee.org.uk/plan9/ftpfs..patch/diff.context

Re: [9fans] ftpfs ahould not expose "." and ".." directories

[Pietro Gagliardi]

You do realize using strncmp means that a filename like .abc
or ..whatever will also get hidden? There is no notion of a hidden
file in Plan 9, nor is there an option to ls to show them. It's only
necessary to hide . and .., not whatever the other system feels is a
hidden file.

Also note that FTP servers using FAT don't use . to hide files -
there's a bit in the attribute field. This will mean trouble for one
with long file names, where the placement of periods is much more
lenient.

664a665,666
 >			if(!strcmp(".", field[7]) || !strcmp("..", field[7]))
 >				return nil;
675a678,679
 >			if(!strcmp(".", field[8], 2) || !strcmp("..", field[8]))
 >				return nil;
686a691,692
 >			if(!strcmp(".", field[9]) || !strcmp("..", field[9]))
 >				return nil;
697a704,705
 >			if(!strcmp(".", field[3]) || !strcmp("..", field[3]))
 >				return nil;
712a721,722
 >			if(!strcmp(".", field[0]) || !strcmp("..", field[0]))
 >				return nil;


On Apr 28, 2008, at 4:48 AM, eekee57 wrote:

> Hi all. I had a problem trying to use dircp with ftpfs the other day,
> and made a little patch to ftpfs to fix it.
>
> The Problem: Many operating systems expose the psuedo-directories "."
> and ".." in their directory structure, and understandably many FTP
> servers running on those operating systems pass the pseudo-directories
> on to their clients. Plan 9 does does not expose those psuedo-
> directories, so Plan 9's tar program does not treat them specially.
> ftpfs does not hide the pseudo-directories, so Plan 9 tar (and thus
> the dircp script too) will fail on encountering them, getting into a
> loop until the sequence of directory/../directory/../directory/../
> etc. just gets too long. Note that tar may fail to pack all files in
> the tree before failing.
>
> My Fix: I have added a little code to ftpfs to hide the "." and ".."
> directories when the server operating system is detected as UNIX,
> Windows-NT, or Plan 9. I included the Plan 9 case because these 3
> operating systems are lumped together in the code, and the heuristics
> to tell them apart by detail may be fooled by some server which
> happens to list files in a similar manner.
>
> My code consists of 5 near-identical if statements in the function
> that parses each line returned from an ftp LIST or NLST command:
>
> 664a665,666
>> 			if(!strncmp(".", field[7], 2) || !strncmp("..", field[7], 3))
>> 				return nil;
> 675a678,679
>> 			if(!strncmp(".", field[8], 2) || !strncmp("..", field[8], 3))
>> 				return nil;
> 686a691,692
>> 			if(!strncmp(".", field[9], 2) || !strncmp("..", field[9], 3))
>> 				return nil;
> 697a704,705
>> 			if(!strncmp(".", field[3], 2) || !strncmp("..", field[3], 3))
>> 				return nil;
> 712a721,722
>> 			if(!strncmp(".", field[0], 2) || !strncmp("..", field[0], 3))
>> 				return nil;
>
> return nil results in ftpfs ignoring that line of the listing
> entirely. strncmp() may not be the best function as it is supposed to
> compare lexicographically. I'm not sure whether a "lexicographic"
> comparison is appropriate, but I think Plan 9 strncmp is currently a
> simple byte-by-byte comparison.
>
> Patched /sys/src/cmd/ip/ftpfs/proto.c file:
> http://eekee.org.uk/plan9/ftpfs..patch/proto.c
>
> Also FYC are an ed script and a context diff:
> http://eekee.org.uk/plan9/ftpfs..patch/diff.ed
> http://eekee.org.uk/plan9/ftpfs..patch/diff.context
>

Re: [9fans] ftpfs ahould not expose "." and ".." directories

[Juan Céspedes]

On Mon, Apr 28, 2008 at 12:19 PM, Pietro Gagliardi <pietro10@mac.com> wrote:
> You do realize using strncmp means that a filename like .abc or ..whatever
> will also get hidden?

False.  He used strncmp(".", field[8], 2), which matches the first 2
bytes, i.e.,
'.' and '\0'.

But I agree with you: strcmp() would be better here.

Juan

Re: [9fans] ftpfs ahould not expose "." and ".." directories

[Charles Forsyth]

just for completeness, in plan 9 code it also would be
	if(strcmp(".", field[8]) == 0 ...)
etc. not `!strcmp', and indeed it is that way elsewhere in ip/ftpfs.c
similarly, it is usually
	if(p != nil)
		...
not
	if(!p)

there are other guidelines in style(6)

Re: [9fans] ftpfs ahould not expose "." and ".." directories

[Charles Forsyth]

> similarly, it is usually
> 	if(p != nil)
> 		...
> not
> 	if(!p)

ha ha. sorry i meant
	if(p == nil)
not
	if(!p)

Re: [9fans] ftpfs ahould not expose "." and ".." directories

[erik quanstrom]

>> similarly, it is usually
>> 	if(p != nil)
>> 		...
>> not
>> 	if(!p)
>
> ha ha. sorry i meant
> 	if(p == nil)
> not
> 	if(!p)

personal opinion here.

while i appreciate the sentiment behind nil, it breaks
down for me around the edges.  zero is the one value that
can be assigned to anything.  i think the c standard
thinks about zero like andy worhol thinks about coke.

	you know that
	pointers can be zero
	and integers can be zero
	your ptr can be zero, too.
	a zero is a zero and
	no amount of casting about
	will get you a better zero.

(all things being equal, i'd rather have a coke than a zero,
but i digress....)

what it does get you is longer lines, which many folk still wrap
at 80 characters.  and all things being equal, i find unwrapped
lines easier to read.

- erik

Re: [9fans] ftpfs ahould not expose "." and ".." directories

[eekee57]

Honestly I went with strncmp() over strcmp() on little more than a
hunch. I actually prefer strcmp() as looking cleaner, with one less
arg and no need to remember the existence fo the null at the end.
Maybe I'll change it.

As to the style of logic, strncmp() and strcmp() both return zero for
an exact match, a positive number if arg1 is lexicographically greater
than arg2, and a negative number if arg1 is less. This is not strictly
a boolean output, so my choice of !strncmp(...) is probably bad style
anywhere. I remember old assembly language too well.

How about this for style?
                   if(strcmp(".", field[7]) == 0 || strcmp("..",
field[7]) == 0)
                            return nil;

Re: [9fans] ftpfs ahould not expose "." and ".." directories

[roger peppe]

personally, since you're using it so many times, i'd
be tempted to write a little function, say "isdot" or "ishidden",
just to keep the code looking nice. that way if someone decides
to change the style, there's only one place to do it in.

On Tue, Apr 29, 2008 at 9:32 AM, eekee57 <eekee57@fastmail.fm> wrote:
> Honestly I went with strncmp() over strcmp() on little more than a
>  hunch. I actually prefer strcmp() as looking cleaner, with one less
>  arg and no need to remember the existence fo the null at the end.
>  Maybe I'll change it.
>
>  As to the style of logic, strncmp() and strcmp() both return zero for
>  an exact match, a positive number if arg1 is lexicographically greater
>  than arg2, and a negative number if arg1 is less. This is not strictly
>  a boolean output, so my choice of !strncmp(...) is probably bad style
>  anywhere. I remember old assembly language too well.
>
>  How about this for style?
>                    if(strcmp(".", field[7]) == 0 || strcmp("..",
>  field[7]) == 0)
>                             return nil;
>
>