LogicalFile provider usability

Jan Synacek jsynacek at redhat.com
Fri Sep 6 12:29:30 UTC 2013


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 at redhat.com> 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


More information about the openlmi-devel mailing list