LogicalFile provider usability

[Jan Synacek]

All LogicalFile classes as well as LMI_UnixFile require information about the
filesystem (its CreationClassName and UUID/partition name) and the type of the
file (is it a directory/symlink/blockdevice/...?) to be known before it's
possible to call GetInstance() on them.

Now on the client side, if I want show information about a file, I only want to
specify its path, nothing else. And that's a problem, because I usually have no
idea what the file's type and the partition it lies on is, that's why I want to
ask the provider in the first place.

Currently, the provider checks for all those key properties and returns an error
if they are not present, or they are incorrect. So, on the client side, I have
to provide information that I don't know, and on the server side, it requires
those pieces of information, otherwise an error is raised. Which leads me to a
few questions.

1) What is the purpose of FSCreationClassName, FSName and LFCreationClassName in
the LMI_UnixFile class? If my understanding is correct, in the linux
environment, it should be safe to ignore those, because it is impossible for any
two files on the filesystem to have different paths and actually be the same
file (following symlinks doesn't count here). In other words, file's path should
be enough to unambiguously identify that file. Please, correct me if I'm wrong.

2) Is there a way how to find out what the aforementioned key properties are?

As for the solution, I'm for simply ignoring FSCreationClassName, FSName and
LFCreationClassName in the provider.

Comments appreciated.

Cheers,
-- 
Jan Synacek
Software Engineer, Red Hat

[Tomáš Smetana]

On Thu, 05 Sep 2013 15:25:05 +0200
Jan Synacek <jsynacek(a)redhat.com&gt; wrote:

>  1) What is the purpose of FSCreationClassName, FSName and
>  LFCreationClassName in the LMI_UnixFile class? If my understanding is
>  correct, in the linux environment, it should be safe to ignore those,
>  because it is impossible for any two files on the filesystem to have
>  different paths and actually be the same file (following symlinks doesn't
>  count here). In other words, file's path should be enough to unambiguously
>  identify that file. Please, correct me if I'm wrong. 
What about hard links? Do they count? I think it's the {device ID, inode
number} pair that uniquely identifies a "physical file". Not the path though.

Regards,
-- 
Tomáš Smetana
Platform Engineering, Red Hat

[Jan Synacek]

On 09/06/2013 10:12 AM, Tomáš Smetana wrote:
>  On Thu, 05 Sep 2013 15:25:05 +0200
>  Jan Synacek <jsynacek(a)redhat.com&gt; wrote:
>  
> > 1) What is the purpose of FSCreationClassName, FSName and
> > LFCreationClassName in the LMI_UnixFile class? If my understanding is
> > correct, in the linux environment, it should be safe to ignore those,
> > because it is impossible for any two files on the filesystem to have
> > different paths and actually be the same file (following symlinks doesn't
> > count here). In other words, file's path should be enough to unambiguously
> > identify that file. Please, correct me if I'm wrong.
>  
>  What about hard links? Do they count? I think it's the {device ID, inode
>  number} pair that uniquely identifies a "physical file". Not the path though.
I should clarify what I meant by "unambiguosly identifying a file". From the
provider's point of view, it actually doesn't matter if it's a hard link or
the
actual file. It uses lstat(2) inside to get the info about the file. So yes, if
there's a file that has a hard link somewhere on the filesystem, it's
essentially the same file, but it has two "instances". You can cat
<path-to-the-file> or cat <path-to-the-file's-hardlink>. You can do the
same
with GetInstance(). Two different paths, two different instances, but on the
filesystem, the same file.

I hope my explanation makes stuff a bit clearer.

-- 
Jan Synacek
Software Engineer, Red Hat

[Stephen C. Tweedie]

On Fri, 2013-09-06 at 10:32 +0200, Jan Synacek wrote:
>  On 09/06/2013 10:12 AM, Tomáš Smetana wrote:
>  > On Thu, 05 Sep 2013 15:25:05 +0200
>  > Jan Synacek <jsynacek(a)redhat.com&gt; wrote:
>  > 
>  >> 1) What is the purpose of FSCreationClassName, FSName and
>  >> LFCreationClassName in the LMI_UnixFile class? If my understanding is
>  >> correct, in the linux environment, it should be safe to ignore those,
>  >> because it is impossible for any two files on the filesystem to have
>  >> different paths and actually be the same file (following symlinks doesn't
>  >> count here). In other words, file's path should be enough to unambiguously
>  >> identify that file. Please, correct me if I'm wrong.
>  > 
>  > What about hard links? Do they count? I think it's the {device ID, inode
>  > number} pair that uniquely identifies a "physical file". Not the path
> though.
>  
>  I should clarify what I meant by "unambiguosly identifying a file". From the
>  provider's point of view, it actually doesn't matter if it's a hard link or
> the
>  actual file. 
There is no distinction between a hard link and the actual file; all
files are effectively hard links.  Files start off with one link (one
directory entry pointing to the inode); when you hard link, all you're
doing is adding another link to the same file, and both old and new are
equally valid.

>   It uses lstat(2) inside to get the info about the file. So yes, if
>  there's a file that has a hard link somewhere on the filesystem, it's
>  essentially the same file, but it has two "instances".  
This depends what you mean by "instance".  If you mean "directory
entry"
or "path", then this is correct;

>  You can cat
>  <path-to-the-file> or cat <path-to-the-file's-hardlink>.  
but this is an artificial distinction, it's really
<one-path-to-the-file> and <a-different-path-to-the-file>.  There is no
way to tell which is the original path and which is the newer one.

>  You can do the same
>  with GetInstance(). Two different paths, two different instances, but on the
>  filesystem, the same file. 
Right.  What we need to understand is whether the distinction matters;
earlier you said

>  >> it is impossible for any two files on the filesystem to
> have
>  >> different paths and actually be the same file 
but this is exactly what hard links do (and also bind mounts, btw.) 

What exactly about an "instance" do you rely on being unique?  Bind
mounts might be equally complex to handle here, as they result in
replicating not just the referenced file, but the actual directory
entries too (ie. renaming a file in one mount will instantly be
reflected in other bind mounts too.)

--Stephen

[Jan Synacek]

On 09/06/2013 01:29 PM, Stephen C. Tweedie wrote:
>  On Fri, 2013-09-06 at 10:32 +0200, Jan Synacek wrote:
> > On 09/06/2013 10:12 AM, Tomáš Smetana wrote:
> >> On Thu, 05 Sep 2013 15:25:05 +0200
> >> Jan Synacek <jsynacek(a)redhat.com&gt; wrote:
> >>
> >>> 1) What is the purpose of FSCreationClassName, FSName and
> >>> LFCreationClassName in the LMI_UnixFile class? If my understanding is
> >>> correct, in the linux environment, it should be safe to ignore those,
> >>> because it is impossible for any two files on the filesystem to have
> >>> different paths and actually be the same file (following symlinks
> doesn't
> >>> count here). In other words, file's path should be enough to
> unambiguously
> >>> identify that file. Please, correct me if I'm wrong.
> >>
> >> What about hard links? Do they count? I think it's the {device ID, inode
> >> number} pair that uniquely identifies a "physical file". Not the path
> though.
> >
> > I should clarify what I meant by "unambiguosly identifying a file". From
> the
> > provider's point of view, it actually doesn't matter if it's a hard link
> or the
> > actual file.
>  
>  There is no distinction between a hard link and the actual file; all
>  files are effectively hard links.  Files start off with one link (one
>  directory entry pointing to the inode); when you hard link, all you're
>  doing is adding another link to the same file, and both old and new are
>  equally valid.
>  
> >  It uses lstat(2) inside to get the info about the file. So yes, if
> > there's a file that has a hard link somewhere on the filesystem, it's
> > essentially the same file, but it has two "instances". 
>  
>  This depends what you mean by "instance".  If you mean "directory
> entry"
>  or "path", then this is correct;
>  
> > You can cat
> > <path-to-the-file> or cat <path-to-the-file's-hardlink>. 
>  
>  but this is an artificial distinction, it's really
>  <one-path-to-the-file> and <a-different-path-to-the-file>.  There is no
>  way to tell which is the original path and which is the newer one.
>  
> > You can do the same
> > with GetInstance(). Two different paths, two different instances, but on the
> > filesystem, the same file.
>  
>  Right.  What we need to understand is whether the distinction matters;
>  earlier you said
>  
> >>> it is impossible for any two files on the filesystem to have
> >>> different paths and actually be the same file
>  
>  but this is exactly what hard links do (and also bind mounts, btw.) 
>  
>  What exactly about an "instance" do you rely on being unique?  Bind
>  mounts might be equally complex to handle here, as they result in
>  replicating not just the referenced file, but the actual directory
>  entries too (ie. renaming a file in one mount will instantly be
>  reflected in other bind mounts too.) 
Well, my original concern was if there is a way to specify more files by one
path. It just takes me a while to get the question right:)

So, my understanding is that there is no such way. At any given time,
/home/jsynacek/file is always only one file.

-- 
Jan Synacek
Software Engineer, Red Hat

[Stephen C. Tweedie]

Hi,

On Fri, 2013-09-06 at 14:29 +0200, Jan Synacek wrote:
>  On 09/06/2013 01:29 PM, Stephen C. Tweedie wrote:
>  > On Fri, 2013-09-06 at 10:32 +0200, Jan Synacek wrote: 
>  Well, my original concern was if there is a way to specify more files
> by one
>  path. It just takes me a while to get the question right:) 
Ahh, OK.

>  So, my understanding is that there is no such way. At any given
> time,
>  /home/jsynacek/file is always only one file. 
Nearly always, yes.  The exceptions are special cases that you can
probably ignore for now.

There are two places where this breaks down.  One is "magic" files which
are context-dependent; /proc/self/ is the obvious one, which will point
to a completely different /proc/ subtree depending on which process is
calling it.

Second is filesystem namespaces, where a group of related processes can
be set up to have a distinct set of mount points separate from the
default; and the related chroot functionality which allows different
processes to consider / to be different places within the mounted
hierarchy.  

Both of these allow a given path to resolve to completely different
files depending on which process is calling; but in both cases, any one
process still has a unique mapping.  So as far as the provider itself is
concerned, a path resolves uniquely; as far as the whole system is
concerned, that's only part of the picture.

I'd recommend against worrying about this for now, and just use the
default namespace that the provider lives in.  If we want to expose
additional namespace semantics, that's an optional future feature.

--Stephen

[Jan Synacek]

On 09/06/2013 02:46 PM, Stephen C. Tweedie wrote:
>  Hi,
>  
>  On Fri, 2013-09-06 at 14:29 +0200, Jan Synacek wrote:
> > On 09/06/2013 01:29 PM, Stephen C. Tweedie wrote:
> >> On Fri, 2013-09-06 at 10:32 +0200, Jan Synacek wrote:
>  
> > Well, my original concern was if there is a way to specify more files by one
> > path. It just takes me a while to get the question right:)
>  
>  Ahh, OK.
>  
> > So, my understanding is that there is no such way. At any given time,
> > /home/jsynacek/file is always only one file.
>  
>  Nearly always, yes.  The exceptions are special cases that you can
>  probably ignore for now.
>  
>  There are two places where this breaks down.  One is "magic" files which
>  are context-dependent; /proc/self/ is the obvious one, which will point
>  to a completely different /proc/ subtree depending on which process is
>  calling it.
>  
>  Second is filesystem namespaces, where a group of related processes can
>  be set up to have a distinct set of mount points separate from the
>  default; and the related chroot functionality which allows different
>  processes to consider / to be different places within the mounted
>  hierarchy.  
>  
>  Both of these allow a given path to resolve to completely different
>  files depending on which process is calling; but in both cases, any one
>  process still has a unique mapping.  So as far as the provider itself is
>  concerned, a path resolves uniquely; as far as the whole system is
>  concerned, that's only part of the picture.
>  
>  I'd recommend against worrying about this for now, and just use the
>  default namespace that the provider lives in.  If we want to expose
>  additional namespace semantics, that's an optional future feature.
>   
Ok, thanks for the explanation!

-- 
Jan Synacek
Software Engineer, Red Hat