in reply to Re: Creating shortcuts
in thread Creating shortcuts

Have you tried this?

perlport says

link OLDFILE,NEWFILE

Not implemented. (Mac OS, MPE/iX, VMS, RISC OS)

Link count not updated because hard links are not quite that hard (They are sort of half-way between hard and soft links). (AmigaOS)

Hard links are implemented on Win32 (Windows NT and Windows 2000) under NTFS only.

I tried it, and after changing the original, the changes aren't reflected. Looks like it's just a plain-old copy.

I believe NTFS supports this (cause I read http://www.hlm.inc.ru/ ), but I don't believe perl(activeperl5.6 at least) implements it.

update: some links
Securiteam: [NT] NTFS Hard Links Subvert Auditing
CreateHardlink

update: Well, after looking through my \perl directory, I do find `CreateHardlink' in perl56.dll, so I don't know what's up. I still believe the implementation must be off, cause I create a file, I create a link to it using perl, I append something to , view the file, view the link, and they're different.

update: Whoa, after installing HardLinkMagic, and creating another link to my test file, it worked. This is very bizzare, veeeeeery bizzare.

update: your tests run fine now. I just dragged the files/hardlinks over to notepad, and it just didn't work the first time around. This was just weird (yes I do have NTFS, i checked ;D).

____________________________________________________
** The Third rule of perl club is a statement of fact: pod is sexy.

Replies are listed 'Best First'.
Re: Re: Re: Creating shortcuts
by helgi (Hermit) on Oct 15, 2002 at 11:33 UTC
    Yes, I tested it. Here is an even more through test that worked perectly on my platform, Win2K, NTFS, Activeperl 5.6.1:

    use warnings; use strict; my $file = 'C:/tmp/filename1.txt'; open IN, $file or die "Cannot open $file for reading:$!\n"; print "Contents of $file before linking:\n"; print while (<IN>); close IN; my $link = 'C:/tmp/link.txt'; if (-e $link) { unlink $link or die $!; } link $file,$link or die "Cannot link $link to $file:$!\n"; open LINK, $link or die $!; print "Contents of $link after linking:\n"; print while (<LINK>); close LINK; open (OUT, ">>", $file) or die "Cannot open $file for writing:$!\n"; print OUT "Additional content\n"; close OUT; open IN, $file or die $!; print "Coontents of $file after updating:\n"; print while (<IN>); close IN; open LINK, $link or die "Cannot open $link:$!\n"; print "Contents of $link after updating:\n"; print while (<LINK>); close LINK;
    Printed output:

    Contents of C:/tmp/filename1.txt before linking: Original contents Contents of C:/tmp/link.txt after linking: Original contents Coontents of C:/tmp/filename1.txt after updating: Original contents Additional content Contents of C:/tmp/link.txt after updating: Original contents Additional content
    As you can see, the link is maintained. YMMV on other platforms.

    --
    Regards,
    Helgi Briem
    helgi AT decode DOT is

      I'd never heard of this facility and thought the original post was wrong. However, I can confirm that it does work on NT4 SP6 using AS 5.6.1. Now I just gotta work out some good uses for it.

      The are some caveats though. Q106166

      Kinda reenforces my favorite bugbear with W2K though. Why do I have to waste all that disk storing copies of files that exist in \winnt\system32 in the hidden subdir \winnt\system32\dllcache? Including such important files as winmine.exe 220mb of wasted space! D'oh.

      C:\test>test Contents of ./filename1.txt before linking: This is the contents of filename1.txt Contents of ./link.txt after linking: This is the contents of filename1.txt Coontents of ./filename1.txt after updating: This is the contents of filename1.txt Additional content Contents of ./link.txt after updating: This is the contents of filename1.txt Additional content

      Cor! Like yer ring! ... HALO dammit! ... 'Ave it yer way! Hal-lo, Mister la-de-da. ... Like yer ring!
        Why do I have to waste all that disk storing copies of files that exist in \winnt\system32 in the hidden subdir \winnt\system32\dllcache? Including such important files as winmine.exe 220mb of wasted space! D'oh.

        Same here. I was running low on space on my system drive a while back, didn't have the time to run out and get a new drive. The quick fix was sfc /cachesize=50, where 50 = 50MB. I can't remember if I had to manually clean up the dllcache directory or not ;)

        Look here for documentation, and enjoy all that new disk space - for a few days at least.