Re: Re: Another File::Copy problem

Replies are listed 'Best First'.
Re: Re: Re: Another File::Copy problem by simon.proctor (Vicar) on Mar 06, 2002 at 09:11 UTC
Yes thats a valid file but its been my experience that ... files markers that gits who have used root kits (or some exploit you haven't patched) have been in your system. So I'd avoid using it. The reason why that its a valid file is to do with the way inodes work on Unix. The '.' 'points' to the local directory and '..' to the parent directory. This works in a chain right up to '/'. Consider that as everything in Unix is essentially a file and that only those two files are considered special then what you have created is a dot file called '..'. Of course because its a dot file you have to use 'ls -la' to normally see them. Hence why they are left about in user directories. Also a reason to avoid them. Now if you didn't create that file - I'd be worried :P.	[reply]
Re: Re: Re: Another File::Copy problem by particle (Vicar) on Mar 05, 2002 at 23:30 UTC
now THAT is fantastic! ~Particle ;Þ	[reply]
Re: Re: Re: Another File::Copy problem by rjray (Chaplain) on Mar 06, 2002 at 06:12 UTC
For some reason, you have a sub-directory within `/russ/perl_scripts/monks` whose name is "`...`". The cd command from cygwin does UNIX-like things with `.` and `..`, but `...` is just another dot-file like `.bashrc`. Or directory, in this case. Since you typed `cd .../.` instead of `../..` (what you probably originally meant to type), you used cd to go down into the `...` directory, and then into `.` within it (which we all know means "current dir"[]). So your final destination was `/russ/perl_scripts/monks/...`. --rjray* * Of course we all know that the concepts of `.` and `..` are a little more involved than that. I'm just limiting this to the relevant information.	[reply]
Re: Re: Re: Another File::Copy problem by rbc (Curate) on Mar 06, 2002 at 17:23 UTC
Hmmm ... bash-2.05a$ pwd /russ/perl_scripts/monks bash-2.05a$ ls -la total 26 drwxr-xr-x 2 rbc None 8192 Mar 6 09:20 . drwxr-xr-x 10 rbc None 4096 Feb 22 16:06 .. -rwxr-xr-x 1 rbc None 1121 Mar 5 14:07 colon_bug.pl -rwxr-xr-x 1 rbc None 155 Mar 4 13:11 crazy.PL -rw-r--r-- 1 rbc None 62 Jan 3 12:33 data.txt -rwxr-xr-x 1 rbc None 557 Jan 3 14:48 mytwoarray.pl -rwxr-xr-x 1 rbc None 651 Feb 27 15:25 newbie.pl -rwxr-xr-x 1 rbc None 56 Jan 3 12:45 regextest.pl -rwxr-xr-x 1 rbc None 1355 Jan 8 11:27 select2files.pl -rwxr-xr-x 1 rbc None 1348 Jan 9 12:49 selectDirs.pl -rwxr-xr-x 1 rbc None 467 Jan 3 12:22 timetest.pl -rwxr-xr-x 1 rbc None 386 Jan 3 14:28 twoarray.pl -rw-r--r-- 1 rbc None 452 Mar 5 13:45 undos.pl [download] I don't see any file named "..." I think it is a bug in my version of Cygwin's port of bash. I'll post this on there mailing list. Thanks for all you inputs!	[reply] [d/l]
Re: Re: Re: Re: Another File::Copy problem by snafu (Chaplain) on Jun 19, 2002 at 14:30 UTC
Yeah. I was going to say that its probably a bug since you are on a windows box and even though cygwin does Unix type things, who on earth would h4x0r a windows box from remote and then use Unix type schemes to hide their uber skillz? Another thing that I am not quite sure about is does Cygwin allow remote user connections to a Cygwin shell? I've never seen it. Theoretically, I guess its possible, but who on earth would allow such a thing?!? :) _ _ _ _ _ _ _ _ _ _ - Jim Insert clever comment here...	[reply]