Why mv have no "-R"

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.

Re: Why mv have no "-R"

Listen Up 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.

Re: Why mv have no "-R"

Listen Up 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.

Re: Why mv have no "-R"

Maxwell Lol wrote:
> Listen Up 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

Re: Why mv have no "-R"

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?

Re: Why mv have no "-R"

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

Re: Why mv have no "-R"

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

Re: Why mv have no "-R"

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

Re: Why mv have no "-R"

On Jan 6, 11:25=A0am, Wayne wrote:
>
>
> It can be difficult to realize in Unix files don't have fixed names,
> they only have fixed inode numbers. =A0Any file can have multiple
> names (hard links) and these can be created with "ln", removed
> with "rm", and renamed with "mv". =A0
>[...]
> 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

Thanks a lot!
I searched googlegroups and tested with 'cp' 'mv' 'ln'and hardlink and
symbolic link, it seems clear to me now.

One more question, I can know how many hardlinks one file has by
$ls -l
but how can I delete this file absolutely if I don't know the name of
other hardlinks? Seems like you can't really delete a file if you
don't know its other alias.

Re: Why mv have no "-R"

Janis Papanagnou wrote:
> 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

You're probably right; I was just remembering watching disk I/O
when moving a file, I really don't know FAT32 "under the hood".

And nowadays not all Unix filesystems work that way either; I
think ReiserFS, zfs, and some others don't actually maintain a
separate inode table anymore, but I don't really know. But I
refuse to give up the inode metaphor, it explains so much of
how Unix systems work with files!

-Wayne

Re: Why mv have no "-R"

Jerry wrote:
> On Jan 6, 11:25 am, Wayne wrote:
>>
>>
>> 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".
>> [...]
>> 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
>
> Thanks a lot!
> I searched googlegroups and tested with 'cp' 'mv' 'ln'and hardlink and
> symbolic link, it seems clear to me now.
>
> One more question, I can know how many hardlinks one file has by
> $ls -l
> but how can I delete this file absolutely if I don't know the name of
> other hardlinks? Seems like you can't really delete a file if you
> don't know its other alias.
some 'find' versions have -inum, so once you know the inode, you can use
that in 'find' to search for the others.

Bye, Jojo

Re: Why mv have no "-R"

Jerry wrote:
> On Jan 6, 11:25 am, Wayne wrote:
>>
>> 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".
>> [...]
>> 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
>
> Thanks a lot!
> I searched googlegroups and tested with 'cp' 'mv' 'ln'and hardlink and
> symbolic link, it seems clear to me now.

Yep. Inodes are complicated, but once you understand them you can much
more easily understand permissions, files, directories, and the
commands that work on them.

>
> One more question, I can know how many hardlinks one file has by
> $ls -l
> but how can I delete this file absolutely if I don't know the name of
> other hardlinks? Seems like you can't really delete a file if you
> don't know its other alias.
>

Even if you know the pathnames of the other hard links to a file,
you may not have permission to delete them. Remember in Unix
you need "wx" on a directory to delete a hard link in it; it
doesn't matter if you're the file owner or what permissions
you have on the file itself.

You can find all the hard links to a file using modern find:

find /mount_point -xdev -inum inode_number -print

If that isn't available on your Unix system, I seem to remember
older Unixes had a command "ncheck" that could do this.

If you own the file, you could edit the file to make it a
zero length file. Then, even if there are hard links you can't
remove, it won't matter.

-Wayne

Re: Why mv have no "-R"

Janis Papanagnou writes:

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


Yes.

To be precise, (and perhaps more information that you really need to
know) the *contents* of the file will remain. However, the system will
also have marked those disk blocks as "available for use" and another
program may grab them and fill up the blocks with new data.

But that's going into the internals of the disk structure, and most
operating systems behave the same way. Some disk recovery tools can
recover data that have been "deleted" this way.

If you ever get rid of a computer or disk drive, simply "deleting" the
files doesn't really wipe the data. That's why some people use disk
wipe programs that write over the entire disk with 1's and 0's.

I hear about people who buy used computers off eBay and discover all
sorts of credit card numbers, etc. on the disks. Then again sometimes
you don't even need a disk recovery program - the files were never
deleted.

Re: Why mv have no "-R"

Jerry writes:

> but how can I delete this file absolutely if I don't know the name of
> other hardlinks?

You are essentially fighting the operating system here - it likes to
keep copies around, and delete the data when convenient.

If you need to scrub the data out of your system for security reasons,
see my other post. The military/NSA suggests successive writings of
ones and zeros over the entire (raw) disk - for 5 passes.

I'm not familiar with Unix routines for scrubbing a single file. You
can re-write the contents of the file. But I am not sure if the old
blocks are cached somewhere. And there's the data is the swap
partition that may also keep a copy.