in reply to Another File::Copy problem

from a windows message box on attempting to create 'my:folder'...

A filename cannot contain any of the following characters:
\ / : * ? " < > |

~Particle ;Þ

Replies are listed 'Best First'.
Re: Re: Another File::Copy problem
by rbc (Curate) on Mar 05, 2002 at 23:06 UTC
    I see. Thanks! I was hoping it wasn't a cygwin bug.

    Hey maybe you can explain this strange behavior.

    bash-2.05a$ uname -a CYGWIN_NT-4.0 SRC26 1.3.6(0.47/3/2) 2001-12-08 17:02 i686 unknown bash-2.05a$ pwd /russ/perl_scripts/monks bash-2.05a$ cd .../. bash-2.05a$ pwd /russ/perl_scripts/monks/...
    ... pretty weird huh?
      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.
      now *THAT* is fantastic!

      ~Particle ;Þ

      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.

      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

      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!
        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...