From: Tim Golden on
On 08/07/2010 03:17, imageguy wrote:
>
>> I, too, have multiple versions installed -- newer ones for running code
>> I haven't upgraded; older ones for compatibility testing where needed.
>> I just install to the default c:\pythonxy directories (although I like
>> the idea of a common root) and I put NTFS hardlinks into my general
>> c:\tools directory which is on the path. The out-of-context hardlinks
>> work because of the registry settings which pick up the correct context
>> for each version.
>
> Sorry to be daft here, but what do you mean by a "hardlink" ?
> A windows "Shortcut" ?
>
> I have just installed 2.7 and want to start upgrading some code, but
> alas still want to maintain some 2.5 code too.

Hardlinks have always been present on NTFS, just not very widely advertised.
They are a way of saying that *this* file and *that* file are actually the
*same* file. (They must be on the same volume as they underlying
implementation
relies on pointing to the volume's master index -- the MFT).

They're not copies: if one changes, the other changes.
They're not shortcuts, which are a Shell (ie Desktop) mechanism, not a
filesystem one

I have hardlinks called python26.exe, python31.exe, etc. which point to
c:\python26\python.exe, c:\python31\python.exe etc. and also
a python3.exe which is another link to c:\python31\python.exe but which will
move when python 3.2 is released.

However, this is simply a convenience I use. It's perfectly possible to have
and to use several versions of Python concurrently without this. How you do
it depends on your working practice: whether you use an IDE or
double-click on
..py files or run from a cmd window, etc.

TJG
From: Aahz on
In article <1450078b-d5ee-437f-bd8b-8da26900f254(a)x27g2000yqb.googlegroups.com>,
imageguy <imageguy1206(a)gmail.com> wrote:
>
>Sorry to be daft here, but what do you mean by a "hardlink" ?
>A windows "Shortcut" ?

Just to be clear, a hardlink on NTFS functions almost exactly the same as
a hardlink on a Unix filesystem -- it's a pointer to the same underlying
file.
--
Aahz (aahz(a)pythoncraft.com) <*> http://www.pythoncraft.com/

"....Normal is what cuts off your sixth finger and your tail..." --Siobhan
From: Grant Edwards on
On 2010-07-08, Aahz <aahz(a)pythoncraft.com> wrote:
> In article <1450078b-d5ee-437f-bd8b-8da26900f254(a)x27g2000yqb.googlegroups.com>,
> imageguy <imageguy1206(a)gmail.com> wrote:
>>
>>Sorry to be daft here, but what do you mean by a "hardlink" ?
>>A windows "Shortcut" ?
>
> Just to be clear, a hardlink on NTFS functions almost exactly the same as
> a hardlink on a Unix filesystem -- it's a pointer to the same underlying
> file.

A windows shortcut is more like a Unix symlink (symbolic link), where
the real destination path is a string contained in the link/shortcut
file. That destination path is then evaluated and "dereferenced" when
the link/shortcut is accessed.

--
Grant Edwards grant.b.edwards Yow! Of course, you
at UNDERSTAND about the PLAIDS
gmail.com in the SPIN CYCLE --
From: Stephen Hansen on
On 7/8/10 8:07 AM, Grant Edwards wrote:
> On 2010-07-08, Aahz <aahz(a)pythoncraft.com> wrote:
>> In article <1450078b-d5ee-437f-bd8b-8da26900f254(a)x27g2000yqb.googlegroups.com>,
>> imageguy <imageguy1206(a)gmail.com> wrote:
>>>
>>> Sorry to be daft here, but what do you mean by a "hardlink" ?
>>> A windows "Shortcut" ?
>>
>> Just to be clear, a hardlink on NTFS functions almost exactly the same as
>> a hardlink on a Unix filesystem -- it's a pointer to the same underlying
>> file.
>
> A windows shortcut is more like a Unix symlink (symbolic link), where
> the real destination path is a string contained in the link/shortcut
> file. That destination path is then evaluated and "dereferenced" when
> the link/shortcut is accessed.

This is true, but a windows shortcut is more limited: its a feature of
higher level code in the UI (I don't want to say just Explorer, as the
standard dialogs deal with it too), and not the filesystem. So it only
really works if there's a user specifically clicking through it -- or if
you have code made to look for the .lnk files, parse them (they're
really simple INI files) and deference it manually. At least, IIUC.

--

Stephen Hansen
... Also: Ixokai
... Mail: me+list/python (AT) ixokai (DOT) io
... Blog: http://meh.ixokai.io/

From: Tim Golden on
On 08/07/2010 16:07, Grant Edwards wrote:
> On 2010-07-08, Aahz<aahz(a)pythoncraft.com> wrote:
>> In article<1450078b-d5ee-437f-bd8b-8da26900f254(a)x27g2000yqb.googlegroups.com>,
>> imageguy<imageguy1206(a)gmail.com> wrote:
>>>
>>> Sorry to be daft here, but what do you mean by a "hardlink" ?
>>> A windows "Shortcut" ?
>>
>> Just to be clear, a hardlink on NTFS functions almost exactly the same as
>> a hardlink on a Unix filesystem -- it's a pointer to the same underlying
>> file.
>
> A windows shortcut is more like a Unix symlink (symbolic link), where
> the real destination path is a string contained in the link/shortcut
> file. That destination path is then evaluated and "dereferenced" when
> the link/shortcut is accessed.

Goodness knows I'm probably teaching my grandmother etc. etc. but I
would clarify that a Windows shortcut is a *shell* concept: from the
NTFS point of view, it's just a something.lnk with some opaque contents.

A (>= Vista) NTFS smbolic link is documented as designed "to function just
like Unix links".

TJG