in reply to Moving files

I'm assuming the move function you're using is from File::Copy. If it isn't than any of the following advice is invalid. Next time be sure to mention where you're getting a function if it's not a built-in operator.

Despite what matija said, move() is indeed intended to be used for moving files across filesystem boundaries. It first attempts to rename, which in this case will fail, then it attempts to copy() and unlink.

The problem appears to be that you're attempting to move a directory. Because the rename call fails move() is then calling copy(), which is intended for use on files, not directories.

The solution, in Perl, is to move each individual file undir "$base/$fname2". First, chdir to your source directory, then use File::Find::find on "." to search. If you encounter a directory, create it in your target with mkdir; if you encounter a non-directory move it with File::Copy::move. Be sure to test it and play with File::Find::finddepth or File::Find's preprocess option if you're not getting things in the right order.

Replies are listed 'Best First'.
Re: Re: Moving files
by neilwatson (Priest) on Mar 22, 2004 at 18:28 UTC
    That's awful. What was the design logic behind that? It would be faster to simply use system ("mv ...);

    Neil Watson
    watson-wilson.ca

      I think the author intended it to be used for files. He may be open to a suggestion to extend it for directories (or even a patch?).

      It would be faster to simply use system ("mv ...);

      Go ahead... Not as portable, but if you understand the constraints, there is nothing wrong with that at all.

      One other point to keep in mind is that using system() can be a security issue. Especially if you are passing user input to the system call.

      This node has a quick explanation of the issue.