From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id pBFLcG5a003674 for ; Thu, 15 Dec 2011 22:38:16 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcAAPln6k5KfVM2kGdsb2JhbABDqy8IIgEBAQEJCQ0HFAQhgXIBAQEEEgIsARsdAQMMBgULDS4iAREBBQEOAQ0GEyKjWAqLZYJrhQVAiHECBQuDbogLBI09hzmNdj2DeQ X-IronPort-AV: E=Sophos;i="4.71,359,1320620400"; d="scan'208";a="123565627" Received: from mail-ee0-f54.google.com ([74.125.83.54]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 15 Dec 2011 22:38:10 +0100 Received: by mail-ee0-f54.google.com with SMTP id c50so3453342eek.27 for ; Thu, 15 Dec 2011 13:38:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MDK55l1l/3jWey7Fxlhr/ZBtns6iiq74hnmNLIKMvxI=; b=XLAnZcoJS8yWTSo2Qae1SigN3aK4KP76kMaZ2ie0fc3eZb6ysucjIdOcrF8XNhF/zU rKSVUg2vPQeT87body8rjmGAUicHpLtsRu0UZtM0WTOncl+gQWhy8SdCkth1axy5C8Ow X6DQoe8Te1LReZgGX1YBZ4AgwaRgNS8bt8Hwo= MIME-Version: 1.0 Received: by 10.213.35.13 with SMTP id n13mr921186ebd.4.1323985090651; Thu, 15 Dec 2011 13:38:10 -0800 (PST) Received: by 10.213.10.148 with HTTP; Thu, 15 Dec 2011 13:38:10 -0800 (PST) In-Reply-To: <4EE8D70A.1030207@frisch.fr> References: <4EDE33A0.6070004@gmail.com> <1323760512.9833.9.camel@samsung> <4EE711FB.5020602@frisch.fr> <4EE83C26.7090108@frisch.fr> <4EE86D90.6080409@gmail.com> <4EE87976.4030604@frisch.fr> <1323876479.7750.36.camel@samsung> <4EE8D70A.1030207@frisch.fr> Date: Thu, 15 Dec 2011 22:38:10 +0100 Message-ID: From: Adrien To: Alain Frisch Cc: Gerd Stolpmann , Jonathan Protzenko , Martin DeMello , caml-list@inria.fr Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Caml-list] Some comments on recent discussions On 14/12/2011, Alain Frisch wrote: > On 12/14/2011 04:49 PM, Adrien wrote: >> But windows actually has symlinks. Kind of. Starting with Vista and the >> corresponding NTFS version. But by default you need to be an administrator >> to use them, you can only create a limited number of symlink in a given >> folder afaiu, some functions work on the symlink and some on the target >> (stat()/lstat()). They have a number of limitations and last time I looked >> at them, I found them to be mostly unusable because of their limitations. >> >> They're one quite big issue I've had for packages on windows: if I >> cross-compile a library from Linux, and make a tarball which has a number >> of >> symlink in it. What to do when untarring on windows? Try to create >> symlinks? >> Use hardlinks when possible? Copy the file's contents? Something else? > > Even if Windows supports kinds of symlink internally, this is a rarely > used/exposed features. I think it's a bad idea to rely on them for a > packaging system (targeted to "native" Windows users). They would look > "foreign" to users, and we should expect a lot of bad support from > existing tools. After some discussion and pondering, I think that symlinks won't be stored as-is in the package but will instead be created during some sort of post-install hook (yypkg doesn't work that way but you get the idea). Then, if the OS or FS doesn't handle symlinks in an acceptable way, I think the following fallbacks could be used: 1- if symlink's target is a file in the symlink's folder: use a hardlink 2- if symlink's target is a file in another folder: cp the file 3- if symlink's target is a folder: try to use symlinks 4- if symlink's target is a folder and 3- is impossible, cp -r the folder 3- is based on the optimistic but realistic assumption that there aren't many symlinks to folders in a given folder, therefore avoiding the limit of 31 symlinks in a given folder on windows. I've used the following commands to find how many symlinks to directories I had in a given folder (hope it's right) (on a full slackware): find -P / -mount -type l -xtype d | xargs -L 1 -x dirname | sort | uniq -c | sort -n I got: /usr/man: 11, /etc: 9, /usr/doc/gimp-2.6.11: 8, /usr/include: 7, /usr/X11R6: 7, /media: 7, /usr/lib64/X11: 6, /usr/lib64: 6, ..., /usr/doc: 5, /usr/ 5... That shows the option 3- is quite likely to succeed. Also, note that slackware adds some symlinks to do things the way it wants (it predates Linux' standard fs hierachy ;-) ). I'd be interested in any comments. Thanks. Regards, Adrien Nader