Date:	Tue, 23 Nov 1999 09:24:18 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Laurynas Biveinis <lauras AT softhome DOT net>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: Symlinks...
In-Reply-To:	<38399784.4E3708E4@softhome.net>
Message-ID:	<Pine.SUN.3.91.991123092400.13225G-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Mon, 22 Nov 1999, Laurynas Biveinis wrote:

> > > What will happen if "ln -s
> > > a_short.nam a_very_long_name.with.multiple_long_extensions" is done in plain
> > > DOZE?
> > 
> > This will fail because the second file name is an invalid name on DOS.
> > So `ln' cannot create it.  It's the same as if you replace "ln -s" with
> > "cp".
> 
> If the `ln' itself does this check. If you call `symlink()' from your own
> code, it isn't done.

It's not in `ln', it's inside DOS.

When `ln' is about to make the symlink, it eventually calls a DOS
function to create a file.  When DOS sees a name such as
a_very_long_name.with.multiple_long_extensions, it fails the call with
ENOENT, because such a name is invalid on DOS filesystems.  (The
transparent truncation only works on files that don't use such invalid
constructs, and also don't include characters that DOS doesn't allow
in file names, such as `+', `,', etc.)

The same thing happens if you substitute `cp' for `ln'.  Here, too,
`cp's application code doesn't check these things, it's DOS itself
that fails the call to create the target file.

- Raw text -