From: Ryusuke Konishi <ryusuke-sG5X7nlA6pw@public.gmane.org>
To: dexen.devries-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Cc: linux-nilfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: lscp & friends: indicate filesystem by directory
Date: Tue, 08 Mar 2011 11:31:22 +0900 (JST) [thread overview]
Message-ID: <20110308.113122.255573221.ryusuke@osrg.net> (raw)
In-Reply-To: <201103071051.25290.dexen.devries-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi,
On Mon, 7 Mar 2011 10:51:25 +0100, dexen deVries wrote:
> Hi,
>
> I've suspended issuing my current patches for lscp & friends till I implement
> the functionality Ryusuke mentioned.
>
> Please review the following sketch of algorithm for all interactive utils:
>
> char *dev, *dir, *object;
> char canonical[PATH_MAX + 2];
> struct stat statbuffer;
>
> dev = dir = object = NULL;
>
> if (optind < argc)
> object = argv[optind++];
>
> if (object) {
> stat(object, &statbuffer);
> if (S_ISDIR(statbuffer))
> dir = myrealpath(object, canonical, sizeof(canonical));
> else
> dev = myrealpath(object, canonical, sizeof(canonical));
> }
> else
> dir = getwd(canonical);
>
> /* a new function; traverses directory hierarchy up till it reaches nilfs
> mountpoint */
> if (dir)
> dir = up_to_nilfs_mountpoint(dir);
>
> nilfs_open(dev, dir, ...);
Roughly seems OK to me. (error handling is required at least for the
stat syscall, you know)
> The main difference to the current version is:
> if no object is explicitly indicated on the command line, the tool uses
> current working directory. Thus by default it'd operate on the filesystem
> holding the current working directory -- rather than the first NILFS2 in
> /proc/mounts as it does currently.
Yeah, I think this is a nice idea.
If the current working directory is outside nilfs, it should work same
as before. But this seems to be naturally achieved by the successive
up_to_nilfs_mountpoint() call if it returns NULL for out-of-nilfs
directories. Looks well conceived.
> To indicate which filesystem is to be used, I'd like to print a header line
> roughly like:
> # device: /dev/sdb3
>
> What's your opinion?
This may break compatibility of applications which parse lscp or lssu
output. A separate device line seems a bad idea; it would change the
result for applications just doing a dummy read to skip the header.
I think users do not care about the device name for lscp or lssu
unless they actually want to check it. So, making it an option (and
turning it off by default) would be better.
Also, looks like the device line does not have to be commented out ;)
Thanks,
Ryusuke Konishi
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
prev parent reply other threads:[~2011-03-08 2:31 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-07 9:51 lscp & friends: indicate filesystem by directory dexen deVries
[not found] ` <201103071051.25290.dexen.devries-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2011-03-08 2:31 ` Ryusuke Konishi [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110308.113122.255573221.ryusuke@osrg.net \
--to=ryusuke-sg5x7nla6pw@public.gmane.org \
--cc=dexen.devries-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=linux-nilfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox