Re: Polished FileSystem API proposal

On most unix OSes, symbolic links are build using plain text files
with just the path where they point inside and no more data, and later
the OS identify them as a link instead a text file just by some
special file flags, no more. On Windows, the direct access (.lnk) has
a somewhat similar functionality (files that has the location of other
files), and there was some discussions on the Wine and some Fat FS
mail lists to use them to mimic real symbolic links.

Hard links are more dificult to implement, since they are real link to
a file, and usually this needs to have a counter of how many
references are pointing to them so it doesn't get accidentally
deleted, and this need support on the filesystem itself, while as I
told you before, symbolic links can be mimic in several ways on a
higher layer.

2013/10/30 Brian Stell <bstell@google.com>:
> Good points! I was thinking of the logical functioning and hadn't considered
> the implementation. My understanding is that the UA will map from the
> filename to an actual file using some kind of database. My assumption was
> the logical idea of a link would happen in that layer.
>
>
> On Wed, Oct 30, 2013 at 1:14 AM, piranna@gmail.com <piranna@gmail.com>
> wrote:
>>
>> +1 to symbolic links, they have almost the same functionality that hard
>> links and are more secure and flexible (they are usually just plain text
>> files...).
>>
>> El 30/10/2013 01:42, "Brendan Eich" <brendan@mozilla.com> escribió:
>>
>>> Hard links are peculiar to Unix filesystems. Not interoperable across all
>>> OSes. Symbolic links, OTOH...
>>>
>>> /be
>>>
>>>> Brian Stell <mailto:bstell@google.com>
>>>> October 29, 2013 4:53 PM
>>>> I meant
>>>>
>>>>    eg, V1/dir1/file1, V2/dir1/file1.
>>>
>>>
>



-- 
"Si quieres viajar alrededor del mundo y ser invitado a hablar en un
monton de sitios diferentes, simplemente escribe un sistema operativo
Unix."
– Linus Tordvals, creador del sistema operativo Linux

Received on Wednesday, 30 October 2013 17:24:22 UTC