delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-announce/2013/05/12/15:33:31

Message-Id: <201305121933.r4CJXUCv008550@delorie.com>
Date: Sun, 12 May 2013 21:32:16 +0200
From: Juan Manuel Guerrero <juan DOT guerrero AT gmx DOT de>
To: djgpp-announce AT delorie DOT com
Subject: ANNOUNCE: DJGPP port of GNU Patch 2.7.1 uploaded.
Reply-To: djgpp AT delorie DOT com

This is a port of GNU patch 2.7.1 to MSDOS/DJGPP.

   Patch is a program to apply patches to files.  It accepts a "patch 
script",
   usually produced by file-comparison utility such as Diff, and produces
   modified files by applying this script to old versions of files.

   More often than not, Patch is used with text, usually source, files.
   But it can also patch binary files, although the patch scripts for 
binary
   files tend to be large.



   DJGPP specific changes.
   =======================

   The port offers the same djgpp specific functionality than the previous
   port.  These are:
   - support for numbered backups even on 8+3 file systems;

   - Patch can now ignore the CR characters at the end of each line
     of the patch script, so patching Unix-style text files does not
     convert them to DOS-style files anymore (if you use the --binary
     switch).

   To build this port you will need:
   - to have an OS with LFN support to configure and compile the source
     package.  I have no plans to support SFN systems to build the patch
     binaries.
   - to run the test suite you will need to install the latest mktmpNNb.zip


   As usual, all djgpp specific files (config.bat, diffs, README files, 
etc.)
   are located in the /djgpp directory.

   Please note that there is a directory called /pc/djgpp that contains 
files
   that are part of the official FSF patch distribution.  I have 
inspected those
   files but I have never used them nor I have plans to change this in 
the future.
   Due to the massive use of gnulib code it is no longer possible to 
compile the
   official FSF distribution out-of-the-box.  So I will neither try to 
use those
   files nor to keep them up to date.  I will only use my own ones. If 
someone
   else would like to keep those files up to date it will be OK with me.

   Please also note that some of the tests of the test suite will fail.  
This is
   not a port issue but a test suite issue.  The test suite is very 
posix centric
   so that some test will fail in an environment like DOS/Windows. The most
   notorious test to fail is crlf-handling.  Here the behavior of patch in a
   posix environment is tested and how it works when files to patch or 
the diffs
   file has DOS style EOL.  This is not the same behavior than a 
DOS/DJGPP port
   of patch to work in a DOS/WINDOWS environment.  Not all those test 
will fail
   but some of them.  It makes no sense to try to adjust them because 
they test
   for a behaviour that the port will not offer.  Other tests that will 
fully
   or  partially fail are preserve-mode-and-timestamp, file-modes and fifo.
   For the DJGPP 2.03 port also the symlink test will completely fail.  
This is
   no surprise because DJGPP 2.03 has no real symlink support.  To implement
   symlink support for the DJGPP 2.04 port, among other things, the use of
   __solve_symlinks and __solve_dir_symlinks is required.  Because these
   functions had some bugs that have been fixed in the repository, I have
   decided to compile the 2.04 port using a freshly build library from the
   current cvs repository.  If you want to recompile this port version 
you will
   have to checkout the sources from the repository and compile the library
   yourself.

   One of the most notorious change between this patch version and the 
previous
   one is that this one uses a hash table to administrate the names of 
the files
   it wants to modify or create.  The hash keys are created using the 
st_dev and
   st_ino values.  Especially DJGPP creates the st_ino value using the 
starting
   cluster of the file.  This has the consequence that every time the 
file is
   changed by the patch program by appending some new contents it gets a new
   st_ino.  This has the consequence that stat()ing again produces a 
different
   st_ino for the same file and indeed a new hash key that makes it 
impossible
   to find the already existing entry for this file in the hash table.  
This has
   the nasty consequence, that when patch appends something new to this 
file, it
   does not see that the file already exists and instead of appending to 
it, it
   creates a new one at the same location with the same name overwriting 
the old
   one with the new contains.  To solve this issue it was necessary to 
create
   unique and persistent inode numbers for every file produced by patch.
   Wrapper functions to stat, fstat, open, fopen, close and fclose have been
   written that will keep in sync file name, file descriptor and 
invented inode
   number for every file produced by patch.  See /pc/pc_inode.c for details
   concerning the implementation.

   Another change is that the patch program relaies on some explicit 
values of
   the file type bits stored in the st_mode member of stat. Especially it is
   assumed that every S_IF* bit is encoded by 1 and not by 0.  But 
unfortunately
   this is the case in DJGPP.  DJGPP encodes S_IFREG with zero.  This 
makes the
   code fail.  To avoid to have to change alot of code lines, S_IFREG is 
mapped
   to another value different from zero before used.

   This port supports git-style of patch files.  Unfortunately this type of
   patches encode the file type (like regular file or symlink) of the files
   to be patched as number in the header of the patch file.  This means that
   the patch program reads a git-style patch file and parses the header and
   tries to determinate if the file to be patched will be a regular file
   (S_IFREG) or a symlink (S_IFLNK) or something else.  This means that the
   values of S_IFREG or S_IFLNK are not stored as some kind of symbols 
but as
   those real numbers used to encode them on the OS where the patch file has
   been produced.  This has the consequence that if on a different 
OS/compiler
   this encoding does not match, the patch program will not work 
properly.  An
   inspection of sys/stat.h of linux, bsd and cygwin shows that they all use
   the same encodings for all values stored in the st_mode member of the 
stat
   structure.  Unfortunately DJGPP encodes these values in a 
incompatible way.
   When this port parses that file type number, it _ALWAYS_ interprets it as
   linux/bsd/cygwin encoding of the S_IF* bits and maps it to the DJGPP 
specifc
   values of those bits.  Please note, that the port has no way to 
determinate
   if the number really represents linux/bsd/cygwin encoding or not. If the
   number is not a linux/bsd/cygwin encoding, the mapping will fail an the
   patch cannot be applied.  The port assumes that the following 
encoding for
   the S_IF* bits is valid:
     /* Encoding of the file mode.  */

     #define S_IFMT    0170000  /* These bits determine file type. */

     /* File types.  */
     #define S_IFDIR   0040000  /* Directory.  */
     #define S_IFCHR   0020000  /* Character device.  */
     #define S_IFBLK   0060000  /* Block device.  */
     #define S_IFREG   0100000  /* Regular file.  */
     #define S_IFIFO   0010000  /* FIFO.  */
     #define S_IFLNK   0120000  /* Symbolic link.  */
     #define S_IFSOCK  0140000  /* Socket.  */
   If this assumption is not true, the mapping to DJGPP values of S_IF* bits
   will fail.  Please not that the 2.03 port of patch will always fail 
applying
   git-style patches because it does not support symlinks at all. 
Neitherless
   I do not think that this is a great inconvenience because I think that
   no one will ever port and use git on DOS at all.

   Please note that the FSF distribution of patch no longer can be 
compiled with
   DJGPP out-of-the-box.  If something seems not to work with this port, 
please
   report it first at c.o.m.d. and not at bug-patch AT gnu DOT org.  The maintainer
   will have no idea about what I have done.

   The source package is now distributed configured for both DJGPP 2.03 and
   DJGPP 2.04.  In the top srcdir there is a "_build.203" directory and a
   "_build.204" directory.

   For further information about GNU patch please read the info docs and 
NEWS
   file.


   Here is an extract of the NEWS file showing the user visible changes from
   the last port (patch 2.6.1) to this one:

Changes in version 2.7.1:

* Two critical bug fixes in the "diff --git" format support.
* Clarify the message printed when a patch is expected to empty out and 
delete
   a file, but the file does not become empty.
* Various improvements to messages when applying a patch to a file of 
different
   type (regular file vs. symlink), when there are line ending 
differences (LF
   vs. CRLF), and when in --dry-run mode.
* When in the root directory, allow file names that are absolute or that
   contain a component of "..".
* New --follow-symlinks option to allow to treat symlinks as files: this was
   patch's behavior before version 2.7.
* Ignore when extended attributes cannot be preserved because they are
   unsupported or because permission to set them is denied.
* License clarifications in NEWS and README.
* Portability bug fixes.


Changes in version 2.7:

* Patch no longer gets a failed assertion for certain mangled patches.
* Ignore destination file names that are absolute or that contain a 
component
   of "..".  This addresses CVE-2010-4651.
* Support for most features of the "diff --git" format, including 
renames and
   copies, permission changes, and symlink diffs.  Binary diffs are not
   supported yet; patch will complain and skip them.
* Support for double-quoted filenames: when a filename starts with a double
   quote, it is interpreted as a C string literal.  The escape sequences 
\\, \",
   \a, \b, \f, \n, \r, \t, \v, and \ooo (a three-digit octal number 
between 0
   and 255) are recognized.
* Refuse to apply a normal patch to a symlink.  (Previous versions of patch
   were replacing the symlink with a regular file.)
* When trying to modify a read-only file, warn about the potential problem
   by default.  The --read-only command line option allows to change this
   behavior.
* Files to be deleted are deleted once the entire input has been 
processed, not
   immediately.  This fixes a bug with numbered backup files.
* When a timestamp specifies a time zone, honor that instead of assuming the
   local time zone (--set-date) or Universal Coordinated Time (--set-utc).
* Support for nanosecond precision timestamps.
* Many portability and bug fixes.

----------------------------------------------------------------------------



   The port has been compiled using stock djdev203 (patchlevel 2) and 
consists
   of the two packages that can be downloaded from ftp.delorie.com and 
mirrors
   as (time stamp 2013-05-10):

     Patch 2.7.1 binary and man format documentation:
     ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/pat271b.zip

     Patch 2.7.1 source:
     ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/pat271s.zip


   The binaries have been produced a second time using a freshly compiled
   DJGPP library from the cvs repository.  This package is available at
   ftp.delorie.com and mirrors as (time stamp 2013-05-10):

     Patch 2.7.1 binary and man format documentation:
     ftp://ftp.delorie.com/pub/djgpp/beta/v2gnu/pat271b.zip



   Send Patch specific bug reports to <bug-patch AT gnu DOT org>.
   Send suggestions and bug reports concerning the DJGPP port
   to comp.os.msdos.djgpp or <djgpp AT delorie DOT com>.

Enjoy.

       Guerrero, Juan Manuel <juan DOT guerrero AT gmx DOT de>

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019