Re: Newbie project idea: New POSIX 2008 functionality for ln(1)

2011-09-23 Thread Matthew Dempsky
Hey everyone, so I got a handful of positive responses to this.  I've
replied to a few individuals already, but it's been a hectic week so I
haven't had a chance to reply to everyone yet.  I just wanted to write
a quick note to let everyone know that I *will* get back to you this
weekend, and also a heads up that I already have two or three diffs in
my inbox now for this assignment. :)

I'll also try to think of more little tasks like this and try to
better organize them in the future.

Thanks everyone!

On Mon, Sep 19, 2011 at 9:56 AM, Matthew Dempsky  wrote:
> Here's a small project for someone with basic C programming experience
> and an understanding of UNIX system calls (e.g., file descriptors and
> symbolic vs hard links).  Thought I'd send it to tech@ first in case
> anyone's interested in working on it as a starter project.
>
> POSIX 2008 added two new flags for the ln(1) utility: -P and -L
> (http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ln.html).
> See the spec for details, but the basic idea is that if you have a
> symbolic link "foo" pointing at "bar", then running "ln -L foo xyzzy"
> creates "xyzzy" as a new hard link to the file "bar" (i.e., the same
> as "ln foo xyzzy"), but running "ln -P foo xyzzy" instead creates
> "xyzzy" as a new hard link to the *symbolic link* "foo".
>
> To do this, you'll need to take advantage of the new linkat(2) system
> call (already supported by OpenBSD:
> http://www.openbsd.org/cgi-bin/man.cgi?query=linkat).  The relevant
> new functionality for this project is that it accepts a flag argument
> to control whether to follow symbolic links or not when creating the
> hard link.
>
> I suggest creating some regression tests to check that your new code
> works and hasn't broken anything.  (You can use lstat(2) to
> programmatically check that two directory entries refer to the same
> file by checking that their st_dev and st_ino fields are equal.)
>
> Finally, with some clever use of the new *at(2) functionality, you
> should be able to avoid doing any explicit string concatenation of
> path names.  E.g., for "ln x/file1 y/file2 z/file3 path/to/dir",
> instead of calling:
>
>link("x/file1", "path/to/dir/file1");
>link("y/file2", "path/to/dir/file2");
>link("z/file3", "path/to/dir/file3");
>
> you should be able to do:
>
>int dirfd = open("path/to/dir", O_RDWR|O_DIRECTORY);
>linkat(AT_FDCWD, "x/file1", dirfd, "file1", AT_SYMLINK_FOLLOW);
>linkat(AT_FDCWD, "y/file2", dirfd, "file2", AT_SYMLINK_FOLLOW);
>linkat(AT_FDCWD, "z/file3", dirfd, "file3", AT_SYMLINK_FOLLOW);
>
> Feel free to privately contact me if you're interested and/or have any
> questions about this project.



Newbie project idea: New POSIX 2008 functionality for ln(1)

2011-09-19 Thread Matthew Dempsky
Here's a small project for someone with basic C programming experience
and an understanding of UNIX system calls (e.g., file descriptors and
symbolic vs hard links).  Thought I'd send it to tech@ first in case
anyone's interested in working on it as a starter project.

POSIX 2008 added two new flags for the ln(1) utility: -P and -L
(http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ln.html).
See the spec for details, but the basic idea is that if you have a
symbolic link "foo" pointing at "bar", then running "ln -L foo xyzzy"
creates "xyzzy" as a new hard link to the file "bar" (i.e., the same
as "ln foo xyzzy"), but running "ln -P foo xyzzy" instead creates
"xyzzy" as a new hard link to the *symbolic link* "foo".

To do this, you'll need to take advantage of the new linkat(2) system
call (already supported by OpenBSD:
http://www.openbsd.org/cgi-bin/man.cgi?query=linkat).  The relevant
new functionality for this project is that it accepts a flag argument
to control whether to follow symbolic links or not when creating the
hard link.

I suggest creating some regression tests to check that your new code
works and hasn't broken anything.  (You can use lstat(2) to
programmatically check that two directory entries refer to the same
file by checking that their st_dev and st_ino fields are equal.)

Finally, with some clever use of the new *at(2) functionality, you
should be able to avoid doing any explicit string concatenation of
path names.  E.g., for "ln x/file1 y/file2 z/file3 path/to/dir",
instead of calling:

link("x/file1", "path/to/dir/file1");
link("y/file2", "path/to/dir/file2");
link("z/file3", "path/to/dir/file3");

you should be able to do:

int dirfd = open("path/to/dir", O_RDWR|O_DIRECTORY);
linkat(AT_FDCWD, "x/file1", dirfd, "file1", AT_SYMLINK_FOLLOW);
linkat(AT_FDCWD, "y/file2", dirfd, "file2", AT_SYMLINK_FOLLOW);
linkat(AT_FDCWD, "z/file3", dirfd, "file3", AT_SYMLINK_FOLLOW);

Feel free to privately contact me if you're interested and/or have any
questions about this project.