Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <00da01c42709$d9daca80$66fda287@docbill002>
From: "Bill C. Riemers" <cygwin AT docbill DOT net>
To: <cygwin AT cygwin DOT com>
References: <F76C9B2DA2FC4C4CA0A18E288BBCBCF7082177FA AT nihexchange24 DOT nih DOT gov>
Subject: Re: Emulating hard links on FAT et al.
Date: Tue, 20 Apr 2004 15:00:16 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes

One obvious thing hard links allow is a way to have the same file with
different permissions.  With a symbolic link you need both access
permissions for the symbolic link and actual file.  i.e.

  ln -s /tmp/foo.exe /home/bcr/foo.exe
  chmod ugo-x /tmp/foo.exe
  chmod ugo+x /home/bcr/foo.exe

With a hardlink, you only need access permissions for the hardlink...

Another advantage of a hardlink is the underlying file can not disappear.
i.e.

   ln /tmp/foo.txt /home/bcr/foo.txt
   rm -f /tmp/foo.txt

In this case /home/bcr/foo.txt still exists.

The third significant advantage of a hardlink is it is recognized by the
underlying operating system without ambiguity.

However, I do not really see the advantage of "fake hardlinks", as you would
not have any of these features.  It would just be more like an invisible
symbolic link.

                                             Bill



----- Original Message ----- 
From: "Buchbinder, Barry (NIH/NIAID)" <BBuchbinder AT niaid DOT nih DOT gov>
To: "'A. Alper Atici'" <alperatici AT ttnet DOT net DOT tr>; <cygwin AT cygwin DOT com>
Sent: Tuesday, April 20, 2004 2:27 PM
Subject: RE: Emulating hard links on FAT et al.


> If you do this, remember that it shouldn't be limited to FAT file systems.
> Even though one's version of Windows may be capable of making hard links,
> one may not have the permission level (Administrator) to do so.
>
> But I'm not sure that I see the point of emulating hard links.  It seems
to
> me that you are just making a second type of symbolic link.  Is there
> anything that the emulated hard link could do that the ordinary symbolic
> link cannot?  (Sorry if this is a question with an obvious answer.  I
> haven't had more than fleeting access to a system that would allow me to
> make hard links since 1988).
>
> -----Original Message-----
> From: A. Alper Atici
> Sent: Monday, April 19, 2004 5:52 PM
> To: cygwin AT cygwin DOT com
> Subject: RFI: Emulating hard links on FAT et al.
>
> Hello,
>
> I've been pondering over the prospects of emulating hard links for
> some time. List archives don't show much about it, and I have not come
> across any similar open implementation on the net.
>
> My rudimentary idea of emulating hard links is based on employing a
> new type of windows shortcut which will be regarded as a hardlinking
> file, rather than a symlink, by Cygwin. For this, I hope to figure out
> a possible combination in the magic bitvector byte(word?) in shortcut
> header. Any comments? How about 0x1c?
>
> --
> A. Alper Atici               OpenPGP KeyID: 0xB824F550
>
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Problem reports:       http://cygwin.com/problems.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
>



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/