From: "Albert D. Cahalan" <acahalan@cs.uml.edu>
Message-Id: <200112100544.fBA5isV223458@saturn.cs.uml.edu>
Subject: Re: File copy system call proposal
To: phillips@bonn-fries.net (Daniel Phillips)
Date: Mon, 10 Dec 2001 00:44:54 -0500 (EST)
Cc: quinn@nmt.edu (Quinn Harris),
        linux-kernel@vger.kernel.org (linux-kernel@vger.kernel.org)
In-Reply-To: <E16Chyk-0000zH-00@starship.berlin> from "Daniel Phillips" at Dec 08, 2001 02:57:17 PM
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org

Daniel Phillips writes:

> There's some merit to this idea.  As Peter pointed out,
> an in-kernel cp isn' needed: mmap+write does the job.
> The question is, how to avoid the copy_from_user and
> double caching of data?

No, mmap+write does not do the job. SMB file servers have
a remote copy operation. There shouldn't be any need to
pull data over the network only to push it back again!

The user-space copy operation is also highly likely to
lose stuff that the kernel would know about:

extended attributes   (IRIX, OS/2, NT)
forks / extra streams   (MacOS, NT)
creation time stamp   (Microsoft: not ctime or mtime)
author   (GNU HURD: person who created the file)
file type   (MacOS)
creator app   (MacOS)
unique ID   (Win2K)
mandatory access control data   (Trusted Foo)
non-UNIX permission bits   (every other OS)
ACLs   (NFSv4, NT, Solaris...)
translator   (HURD)
trustees   (NetWare)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/