Article View: gnu.utils.bug
Article #803various things about GNU-tar
From: Robert Bossecker
Date: Thu, 10 Sep 1992 20:32
Date: Thu, 10 Sep 1992 20:32
169 lines
6075 bytes
6075 bytes
hi there
i'm Robert Bossecker from Germany and i'm about to change some
basic routines in GNU-tar like open_archive to support to
handle more archives at the same time.
I already made some extensions to GNU-tar and now i want to
know how can i synchronize to the actual version, and how to
do when i want to change a lot of code and don't want to spent this
time twice when there is a new version meanwhile.
I made some improvements already such as:
changing uid/gid when creating the archive
verbose skipping, helpful if you extract only a few files
from a very big archive, so you can see if it's working.
reset the access-time after dumping the file (like sgi-tar)
a verbose size printing on extracting or creating
a option +to-cmd <cmd> which pipes each file separately with
a popen-call to <cmd>
extract parts of an archive as an archive (works now only with
stdout, requires changes to open_archive to handle more
archives at the same time)
i've also a lot of more ideas:
filelist specified by +files-from could contain two rows
for converting filenames between archive and disk
helpfully if you are receiving long bsd-names and
you only run a 14-char-filename machine.
if the system don't support symlinks, then don't say
unknown filetype 2, try to link it with hard-links
or if hard links doesn't work, copy it.
I'm thinking already over the problem with symlinks
to directories (could hard-link the whole tree).
possibility do specify filenames to dump to the archives
with the same format the archive is given.
[[user]@host:]<filename>
with a remote file given we could try to start a
remote tar with ouput to stdout and piping it
into our local tar and merge locally all given
things to one archive.
Helpfull when the data is spread around the network
without having root-permissions to mount filesystems
over nfs or no nfs available, or if the local
filesys is not big enough to hold all the data
we want to save.
These were only the highlights, some others will follow
in the README-file of tar-1.10 you wrote:
"Various people have been having problems using floppies on a NeXT."
I compiled tar-1.11 (this is my own internal version) on a NeXT
succesfully. the only problem that NeXT Users have is the running
auto-mount-deamon, which is trying to mount any floppy you insert
in the disk-drive. If the floppy does not contain a valid filesystem,
a dialog-window opens and asks for ejecting or initialization of
that floppy, that's not what the user is intended to do.
To get this working the user has to kill the auto-mount-deamon, so
he can insert the floppy with a tar-archive on it and can use it
with the correct device-name (/dev/rfd0b). The next
Problem is to eject the disk. There is no tool reported who's
ejecting the disk from a shell, or without a running auto-mount-
deamon. So i wrote just a few lines to handle this also.
The code for this eject_next.c is appended to this mail message
as a hand-made shar :-). So i want to contribute a little bit
this time and i'm waiting for answer to synchronize my changes
with others.
Robert
------------------------------------cut here--------------------------------
#!/bin/sh
#
# handmade shar archive
#
# Index:
# ./eject_next.c
#
# Compile it with:
# cc -o eject eject_next.c
#
# Usage:
# eject [<device-name>]
#
# if no device-name is given eject want to eject the device /dev/rfd0b
# you can change this in the source right after the beginning of main.
#
cat >eject_next.c <<END_OF_SOURCE
/*
Copyright (C) 1992 Free Software Foundation
GNU tar is distributed in the hope that it will be useful, but WITHOUT ANY
WARRANTY. No author or distributor accepts responsibility to anyone
for the consequences of using it or for whether it serves any
particular purpose or works at all, unless he says so in writing.
Refer to the GNU tar General Public License for full details.
Everyone is granted permission to copy, modify and redistribute GNU tar,
but only under the conditions described in the GNU tar General Public
License. A copy of this license is supposed to have been given to you
along with GNU tar so you can know your rights and responsibilities. It
should be in a file named COPYING. Among other things, the copyright
notice and this notice must be preserved on all copies.
In other words, go ahead and share GNU tar, but don't try to stop
anyone else from sharing it farther. Help stamp out software hoarding!
*/
#include <stdio.h>
#include <sys/ioctl.h>
#include <sys/file.h>
#include <nextdev/disk.h>
main(argc,argv)
int argc;
char *argv[];
{
char *device="/dev/rfd0b";
int i;
int fd;
int ret=0;
if(argc == 1)
{
if((fd=open(device,O_RDONLY,0)) < 0)
{
fprintf(stderr,"Can not open device %s\n",device);
ret |= 1;
}
else
{
if(ioctl(fd,DKIOCEJECT,NULL) < 0)
{
fprintf(stderr,"Some is going wrong with ioctl on device %s\n",device);
ret |= 2;
}
close(fd);
}
}
else
{
for(i=1;i<argc;i++)
{
device=argv[i];
if((fd=open(device,O_RDONLY,0)) < 0)
{
fprintf(stderr,"Can not open device %s\n",device);
ret |= 1;
}
else
{
if(ioctl(fd,DKIOCEJECT,NULL) < 0)
{
fprintf(stderr,"Some is going wrong with ioctl on device %s\n",device);
ret |= 2;
}
close(fd);
}
}
}
exit(ret);
}
END_OF_SOURCE
exit 0
#-------------------------end-----------------------------------
Technical Details
Message-ID:
<9209101632.AA01282@otaru>Path:
arc1-ca.pugleaf.net!sparky!uunet!cis.ohio-state.edu!otaru.UUCP!bossShow Full Headers
Complete Article Headers
Newsgroups: gnu.utils.bug Path: arc1-ca.pugleaf.net!sparky!uunet!cis.ohio-state.edu!otaru.UUCP!boss From: boss@otaru.UUCP (Robert Bossecker) Subject: various things about GNU-tar Message-ID: <9209101632.AA01282@otaru> Sender: gnulists@ai.mit.edu Organization: GNUs Not Usenet Distribution: gnu Date: Thu, 10 Sep 1992 20:32:46 GMT Approved: bug-gnu-utils@prep.ai.mit.edu Lines: 174