Tom Mueller (pkg-discuss) wrote: > Brief problem statement: > > On windows, pathnames are limited to 260 characters. An image that > would otherwise be fine WRT pathname limits cannot be installed with IPS > because the pathnames used in the download directory are longer than the > actual pathname for the image. > > For example, given a file from package mypkg to be installed in: > > foo/bar/baz/glob.jar > > The temporary download file for this might be: > > .org.opensolaris,pkg/download/1234/foo/bar/baz/.mypkg-glob.jar-60223c68a17f1b366c5e9570eac2de892e34e16a > > This is 83 characters longer than the original pathname. > > Possible solution: > > AFAICT, the only reason for putting the pathname of the target file into > the temporary file pathname is so that if the same content is referenced > by two target files, a second copy (or link) of the temporary file can > be made. > > Is this understanding correct? > > A fix for this could be to use the python tempfile.mkstemp call to > create a unique temporary file name for the download file rather than > deriving the name from the target pathname. > > Finally, although this problem only shows up on Windows, is there any > reason why this change can't be made for all platforms just to keep the > code consistent everywhere?
Actually, the current design anticipates caching the downloaded files locally to permit interrupted downloads, local acquisition of content, BitTorrent, etc. Thus, the identity of downloaded files will need to survive a pkg process instance restart, so that the next invocation of pkg can find the all-ready downloaded files. This will also be important for multiple Zones installation/patching; any general redesign of the current mechanism should take this into account. Another constraint on the design is that it needs to support 200K+ files so that a large Solaris image can be downloaded and installed efficiently. We could place all downloaded files into a single directory, but during initial work w/ UFS we ran into its 32K files/directory limitation. I understand Windows has some performance limits here as well. ZFS doesn't really care, although performance is better w/ less than 100K files/directory and having the command line utils not complain 'Arg list too long' is nice too. Once possible out is to do the same thing on the client as we do on the repo and break up the file hash into directories.... - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
