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 matt...@dempsky.org 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.