Menu
▾
▴
arpix-devel — The Arpix project development mailing list
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(36) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(21) |
Feb
(63) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
|
From: Simo S. <sim...@ti...> - 2001-01-28 22:46:24
|
Giovanni Corriga wrote: > > On 28 Jan 2001 15:31:02 +0100, Hongli Lai wrote: > > On Sun, 28 Jan 2001 14:59:05 Giovanni Corriga wrote: > > > Here are the latest patches to tarlib. I have used diff -u. > > > > Committed. > > Could you send me a summary of what you did? > > Here it is: > > Apart from basic functions (open, read etc.), only tl_getfilelist() has > been implemented. > It does return a GList of fileinfo structs. > Each fileinfo struct holds info about a file: > > name > type > size > access mode > user and group id > user and group name > link name (if the file is a symbolic or hardlink) > device major and minor number (if the file is a device) > > Supported file types are: > > regular files > directories > symbolic and hard links > block and character device files. > > Are NOT supported: > > file names longer than 99 chars (and links to those kind of files) why??? > multivolume archives not necessary (I think they are ever seen only on tapes). > sparse headers > fifo files > > Right now, tl_getfilelist() returns NULL when it finds an unsupported > file. Maybe should it simply skip it? no, better return that the archive contains untarable data for libgarp and tell the user to use gnutar for this. > > > > > BTW, I think it's better if you sumbit patches to the mailing > > list instead of to me. > > That way I can use the archive to look for old patches. > > that's a good idea. As Giovanni I'm a bit busy and my contribs will be a bit low for a while. Bye, Simo. -- sim...@ti... http://www.geocities.com/SiliconValley/9757 |
|
From: Giovanni C. <val...@li...> - 2001-01-28 18:07:03
|
On 28 Jan 2001 15:31:02 +0100, Hongli Lai wrote: > On Sun, 28 Jan 2001 14:59:05 Giovanni Corriga wrote: > > Here are the latest patches to tarlib. I have used diff -u. > > Committed. > Could you send me a summary of what you did? Here it is: Apart from basic functions (open, read etc.), only tl_getfilelist() has been implemented. It does return a GList of fileinfo structs. Each fileinfo struct holds info about a file: name type size access mode user and group id user and group name link name (if the file is a symbolic or hardlink) device major and minor number (if the file is a device) Supported file types are: regular files directories symbolic and hard links block and character device files. Are NOT supported: file names longer than 99 chars (and links to those kind of files) multivolume archives sparse headers fifo files Right now, tl_getfilelist() returns NULL when it finds an unsupported file. Maybe should it simply skip it? > > BTW, I think it's better if you sumbit patches to the mailing > list instead of to me. > That way I can use the archive to look for old patches. > -- |
|
From: Giovanni C. <val...@li...> - 2001-01-28 12:06:35
|
On 28 Jan 2001 11:35:38 +0100, Hongli Lai wrote: > We are almost ready for the 0.1 release. > What's the current status of tarlib extraction? > > > _______________________________________________ > Arpix-devel mailing list > Arp...@li... > http://lists.sourceforge.net/lists/listinfo/arpix-devel Status: not started yet, unfortunately. I have been (and still I am) busy with examinations, so I couldn't work on tarlib. In the past days, I have added hard links and device files support to tl_getfilelist(). With FIFO support, all posix file types will be supported (GNU extensions may be added later). Even if extraction is not implemented yet, I think it will be easy to do it. I think I can send you something by the end of the next week. Bye Giovanni -- |
|
From: Hongli L. <ho...@te...> - 2001-01-28 10:34:52
|
We are almost ready for the 0.1 release. What's the current status of tarlib extraction? |
|
From: Hongli L. <ho...@te...> - 2001-01-23 15:15:34
|
|
From: Giovanni C. <val...@li...> - 2001-01-21 21:32:39
|
Hi! I've added symlinks capabilities to tl_getfilelist. I'm sending the patches to Hongli. If anyone can use a non GNU version of tar (Solaris?), can he please send me a test archive? The test archive should contain regular files, directories and symlinks. Thanks Giovanni |
|
From: Hongli L. <ho...@te...> - 2001-01-17 13:58:52
|
committed, thanks |
|
From: Simo S. <sim...@ti...> - 2001-01-03 22:42:05
|
Hongli Lai wrote: > > > Sorry, > > forgot to advice that the path passed to zlextract is still ignored, I > > will fix it soon. > > Have you checked otherwise that directories and files got the right > > permission over extraction? > > ??????????????? > Anyway, have you written any directory-creating code yet? > If not, I can write it. > yes, stored directories are created (see make_dir function). -- sim...@ti... http://www.geocities.com/SiliconValley/9757 |
|
From: Hongli L. <ho...@te...> - 2001-01-03 09:53:09
|
> Sorry, > forgot to advice that the path passed to zlextract is still ignored, I > will fix it soon. > Have you checked otherwise that directories and files got the right > permission over extraction? ??????????????? Anyway, have you written any directory-creating code yet? If not, I can write it. |
|
From: Simo S. <sim...@ti...> - 2001-01-02 22:52:45
|
Hongli Lai wrote: > > Directories are not created when extracting a file with a path. > Sorry, forgot to advice that the path passed to zlextract is still ignored, I will fix it soon. Have you checked otherwise that directories and files got the right permission over extraction? -- sim...@ti... http://www.geocities.com/SiliconValley/9757 |
|
From: Hongli L. <ho...@te...> - 2001-01-02 11:15:36
|
Directories are not created when extracting a file with a path. |
|
From: Hongli L. <ho...@te...> - 2001-01-01 22:08:48
|
Simo, I committed your ziplib patch. But it seems to be broken. Look at garp-zip.c (garp_zip_extract_files). GnomeZip crashes before it writes to disk. |
|
From: Giovanni C. <val...@li...> - 2000-12-29 05:09:27
|
Hongli Lai wrote: >=20 > It's a surprise! ^_^ >=20 Aargh! I'll be in Rome for New Year, and won't be back home till 01/03=2E :-( I'll have to find an Internet Caf=E8 to check the mail ;-) |
|
From: Hongli L. <ho...@te...> - 2000-12-27 21:21:21
|
It's a surprise! ^_^ |
|
From: Hongli L. <ho...@te...> - 2000-12-27 10:08:24
|
Everytime when I compile gnomezip/src/main.c, it gives warnings: main.c: In function `main': main.c:41: warning: statement with no effect main.c:42: warning: statement with no effect It's about the following lines: bindtextdomain (PACKAGE, PACKAGE_LOCALE_DIR); textdomain (PACKAGE); I encounter this warning in EVERY piece of software I write that uses localization through gettext, but never in software that anybody else writes! I compared my sources to other sources many times, but I couldn't find out what's wrong! Could anybody look at it? |
|
From: Simo S. <sim...@ti...> - 2000-12-26 14:30:10
|
Hongli Lai wrote: > > Simo, will you look at it? > It is probably a ziplib issue. > Look for "FIXME: g_parse_perm() doesn't work!" in garp-zip.c > Fixed, it was my error (I converted in hexadecimal an octal number that had to be octal :( - conversion removed) I will try to cvs things up! -- sim...@ti... http://www.geocities.com/SiliconValley/9757 |
|
From: Hongli L. <ho...@te...> - 2000-12-26 08:31:56
|
Simo, will you look at it? It is probably a ziplib issue. Look for "FIXME: g_parse_perm() doesn't work!" in garp-zip.c |
|
From: Giovanni C. <val...@li...> - 2000-12-25 22:35:07
|
Hongli Lai wrote: > > How do parse time_t into a human-readable string like "20:30" ? > Have a look to ctime() and similars. Giovanni |
|
From: Giovanni C. <val...@li...> - 2000-12-25 22:35:05
|
Hongli Lai wrote: > > I've added 3 new fields (Owner, Group, Permission) to GarpTar in order to > be in sync with tarlib. > Does anybody know how to parse the permission bits (mode_t) to a string? > (something like "rwxr--r--" as shown by ls) > In the standard header <sys/types.h> there are some symbolic constants used for open() calls (S_IRUSR etc) that allow decoding of a mode_t value. When deciding how to store access right information in fileinfo struct, I chose to use a mode_t value instead of an octal string. In this way, is very easy to set access rights of file extracted from tar archives. In the other way, is easier to display access rights info. If you wish, I could use the octal string instead of the mode_t value. Giovanni |
|
From: Hongli L. <ho...@te...> - 2000-12-25 19:50:49
|
How do parse time_t into a human-readable string like "20:30" ? |
|
From: Hongli L. <ho...@te...> - 2000-12-25 19:34:47
|
I've added 3 new fields (Owner, Group, Permission) to GarpTar in order to be in sync with tarlib. Does anybody know how to parse the permission bits (mode_t) to a string? (something like "rwxr--r--" as shown by ls) |
|
From: Hongli L. <ho...@te...> - 2000-12-25 00:17:13
|
I've added Giovanni's name to the website and updated the news section. |
|
From: Simo S. <sim...@ti...> - 2000-12-24 00:19:18
|
from hongli: > ??????????????? > Which OS doesn't support file streams? > Isn't file streams part of ANSI C? > > And are you suggesting fdopen() instead of fopen() ? from giovanni: > I prefer open() calls too, but I found that POSIX-style calls have > nothing like ftell() which I think may be useful, esp. in extracting or > deleting files. > Should my guess happen to be wrong, I'd happily switch to open() calls. I don't mind which (SunOS 2.5?) but some OS does not support more than 256 file descriptors with streams, and there are some other little issues. So I do not like at all using file streams with libraries (which may be used with other progs too), and so I don't like fdopen as it uses streams. from hongli: > So should I change "sizeof(char) * 8" to 8 > and "sizeof(char)*TMAGLEN" to TMAGLEN? I think so! from giovanni: > I could have used strcmp() as well, but AFAIK memcmp() is more efficient > than strcmp(), even when comparing strings. So I prefered to force a > string comparison by use of memcmp(), but I had to be sure that it would > have compared 8 chars, not 8 bytes. > Do you think I should use strcmp(), instead of this hack? If I have not misunderstanded the code, magic is retrieved directly from file, so it HAS 8 bit characters inside, and if you compare it in a system that have longer than 8 bit the result will be probably false. Using memcmp is just fine. -- sim...@ti... http://www.geocities.com/SiliconValley/9757 |
|
From: Hongli L. <ho...@te...> - 2000-12-23 17:45:57
|
Inbox X-Mutt-Fcc: Sentbox Content-Length: 211 Lines: 5 Date: Sat, 23 Dec 2000 18:41:46 +0100 Sender: arp...@li... Errors-To: arp...@li... X-BeenThere: arp...@li... X-Mailman-Version: 2.0 Precedence: bulk Reply-To: arp...@li... List-Help: <mailto:arp...@li...?subject=help> List-Post: <mailto:arp...@li...> List-Subscribe: <http://lists.sourceforge.net/mailman/listinfo/arpix-devel>, <mailto:arp...@li...?subject=subscribe> List-Id: <arpix-devel.lists.sourceforge.net> List-Unsubscribe: <http://lists.sourceforge.net/mailman/listinfo/arpix-devel>, <mailto:arp...@li...?subject=unsubscribe> List-Archive: <http://lists.sourceforge.net/archives//arpix-devel/> Committed. Thank you, but I prefer patches. Make sure that before you make any modifications in your source that you update the source code from CVS, then make changes, then make a patch with diff -c or diff -u |
|
From: Giovanni C. <val...@li...> - 2000-12-23 16:50:39
|
Hi! I'have added some features to tl_getfilelist(). It now returns much more information: Name Size Access rights (a mode_t value, that may be used in chmod() calls) Owner's name and group (both as string and as number (uid/gid)) I'm still not sure about the changes Simo is suggesting... maybe we can apply them later. Giovanni |
