Copy the content of dir1 into dir2,
$ cp -R dir1 dir2
but move the dir1 into dir2, just need
$ mv dir1 dir2
why no '-R'? It came up when I learn the bash basics.

Listen Up <kooperkool@gmail.com> writes:

> Copy the content of dir1 into dir2,
> $ cp -R dir1 dir2
> but move the dir1 into dir2, just need
> $ mv dir1 dir2
> why no '-R'? It came up when I learn the bash basics.
Well the copying really is are more longish thing. But moving is
different (at least on one file system) it's just a change in one
inode. That's really instantanious. If you go over file system
borders, this might be different. But what you do in the end is
"renaming" one thing you do not want to rename the contents of the
directories but the "directory" and so it does not make sense to have
an -R switch....

Regards
Friedrich

--
Please remove just-for-news- to reply via e-mail.

Listen Up <kooperkool@gmail.com> writes:

> why no '-R'? It came up when I learn the bash basics.

the 'mv' command does not move data. Think of it as a "rename" command.

Maxwell Lol wrote:
> Listen Up <kooperkool@gmail.com> writes:
>
>> why no '-R'? It came up when I learn the bash basics.
>
> the 'mv' command does not move data. Think of it as a "rename"
> command.
Well, it does move data (copy to target and delete source) if crossing file
system boundaries.

Bye, Jojo

Thanks to everybody.

So I can take it this way,
'mv' does not really move data(in one file system), it just renames
something--it can be a file or a directory.
While 'cp' copies data, so I have to 'cp' all the files recurisively,
in order to copy a directory into another one!

But another problem: if file2 already exists, in the following
$mv file1 file2
file1 will be renamed as file2, but file2 still exists 'cause 'mv' did
not move data and file2 won't be overwritten, right?

Listen Up wrote:
> Thanks to everybody.
>
> So I can take it this way,
> 'mv' does not really move data(in one file system), it just renames
> something--it can be a file or a directory.
> While 'cp' copies data, so I have to 'cp' all the files recurisively,
> in order to copy a directory into another one!
>
> But another problem: if file2 already exists, in the following
> $mv file1 file2
> file1 will be renamed as file2, but file2 still exists 'cause 'mv' did
> not move data and file2 won't be overwritten, right?

If the directory entry 'file2' is the only "pointer" to the file (i.e.
no additional "hard links" set and no process accessing the file) then
the file file2 *will* be removed. So, in most cases, you will overwrite
the file by using mv. Use mv -i to get asked whether the file should be
overwritten.

Janis

Listen Up wrote:
> Thanks to everybody.
>
> So I can take it this way,
> 'mv' does not really move data(in one file system), it just renames
> something--it can be a file or a directory.
> While 'cp' copies data, so I have to 'cp' all the files recurisively,
> in order to copy a directory into another one!
>
> But another problem: if file2 already exists, in the following
> $mv file1 file2
> file1 will be renamed as file2, but file2 still exists 'cause 'mv' did
> not move data and file2 won't be overwritten, right?

There are no standard user-level commands to delete files in Unix!
Each file has a unique "inode", and one field in this inode is
the count of "hard" links to the file. Commands such as rm, mv,
and cp, don't ever over-write files. If the destination of
mv, cp, ln, or other similar commands is an existing hard link
to some file, then that hard-link is removed and a new one put
in it's place.

In Unix, a file is automatically deleted when its hard link
count goes to zero.

So to fully answer your question, you are right file2 will not
be over-written, however if "file2" was the last hard link to
the file, it will be deleted. If there is another hard link
to that file, it won't be.

It can be difficult to realize in Unix files don't have fixed names,
they only have fixed inode numbers. Any file can have multiple
names (hard links) and these can be created with "ln", removed
with "rm", and renamed with "mv". But none of these commands
do much to the file itself. (Just the link count and timestamps
of a file are affected.) Even when you "mv" a file from one
directory to another, you really delete the hard link from the
first directory and create a new one in the second directory.
(I think with FAT filesystems, the file must actually be moved?)
As others have pointed out in this thread if you "mv" a file from
one disk to another, the file is actually copied, and the
original hard link deleted.

-Wayne

Wayne wrote:
>
> [...] Even when you "mv" a file from one
> directory to another, you really delete the hard link from the
> first directory and create a new one in the second directory.
> (I think with FAT filesystems, the file must actually be moved?)
> [...]

Not necessarily. From faint memories (so correct me if I am wrong)...
FAT directories contain starting sector numbers of files, and the
special FAT sectors define the linkage to subsequent sectors. The
physical sectors of a file don't need to be moved, as long as your
file stays on the same filesystem partition. You _could_ implement
a second directory entry to the same file (something like a hard
link), but there's no support for a reference counter in those OSes.
An early AtariST PC (with a FAT filesystem) had always copied files
that have been moved, but later versions just copied the directory
entries. There was a problem, though, with (moving) directories, as
far as I recall, because the top level (root) directory had a fixed
place in the filesystem and needed special handling.

Janis