1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
|
TODO:
- if an iso is mounted loop-back then vobcopy is unable to find the /dev/
entry in /etc/mtab and resorts to /etc/fstab where something wrong is
written - hence vobcopy doesn't find the device. A new command line option?!
- continue if a part of the image is already there (from a previous try).
Should be doable with the -b code.
- "uname -m" on my machine, you would get: x86_64
(where I've changed the .../lib to .../lib64 in three places), then the
program compiles cleanly
DONE
- some code to prognose when the rip will be ready.
- check more return values of libdvdread calls.
- when copying over an existing file/dir vobcopy makes some trouble (i.e.
it asks to overwrite bla.vob, starts writing to bla.vob.partial and at the
end isn't capable of overwriting bla.vob when it tries to move the
.partial.
- error handling with the errno and strerror function
THOUGHT-ABOUT FEATURES
- being able to specify
- which title
- which chapter
- which angle
- which language(s)
- which subtitle(s)
to copy
- print the total playing time of that title
use EPM to package vobcopy
Users comments|bug-reports:
only -i /dev/rdisk works on osx
if user uses -i then (maybe) force vobcopy to use this dir and not
check the device accordingly.
BUGREPORTS:
Perhaps a verification needs to be added, to catch the situations when
the user specifies a non-existing directory? (and either create it or
abort with "no such directory", instead of claiming there's no free
space)
Hello, i use vobcopy in the mirror manner (vobcopy -m) and since it
works
well in 5.8, i have to tell you that a bug has been introduced since.
In 5.10 vobcopy -m generate error like that : "cannot seek at xxxxx",
and
finaly the result is not readable by xine, ogle or vlc. In fact it
began to
read the movie correctly, but at the first change of vob file, xine (or
others) craches.
Was ist festgestellt
habe:
1. -i /mnt/cd hat nicht funktioniert, aber -i /dev/acd0.
2. -e hat keine Wirkung. Ich habe verschiedene Werte ausprobiert, um
nur wenige MB zu kopieren, trotzdem hat vobcopy weiter kopiert.
Ich habe FreeBSD 5.2.
Bug reporten. Zumindest bei mir geht die Fortschrittsanzeige nicht
ganz bis
auf 100%, selbst wenn schon die naechste Datei angefangen wird, sondern
bleibt kurz davor stehen. Der letzte Schritt wird also nicht mehr
angezeigt.
grafisches frontend mit dem was knoppix-install macht (knx-hddinstall)
----------------------------------------------------------------------
CHECKED
Adam Blazczak <adzio@hotmail.com>
Here's the account of my experiences with compiling vobcopy-1.0.1 on Solaris
9, I hope you find the following information useful.
$ uname -a
SunOS solaris 5.9 Generic_118559-11 i86pc i386 i86pc
configure.sh doesn't work at all.. it's not a biggie, as Makefile works
mostly out of the box with minor adjustment (below) with gcc 3.4.6
$ ./configure.sh
THIS CONFIGURE SCRIPT IS STILL HIGHLY EXPERIMENTAL!
If you think you found a bug, please mail me, thanks! robos@muon.de
./configure.sh: test: argument expected
Below are the code changes I needed to make it all compile properly. If you
decide to add these to the repository, you might want to amend the changes
(possibly make the addition of -lrt and inttypes.h conditional) to let the
other platforms continue to compile without issues.
Regards,
Adam
$ diff -u Makefile.orig Makefile
--- Makefile.orig Sun Apr 15 19:16:29 2007
+++ Makefile Sun Apr 15 19:24:37 2007
@@ -11,7 +11,7 @@
MANDIR = ${PREFIX}/man
LFS = -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
CFLAGS += -I/usr//include
-LDFLAGS += -ldvdread -L/usr//lib
+LDFLAGS += -ldvdread -lrt -L/usr//lib
#This specifies the conversion from .c to .o
$ diff -u vobcopy.h.orig vobcopy.h
--- vobcopy.h.orig Sun Apr 15 18:42:47 2007
+++ vobcopy.h Sun Apr 15 19:05:41 2007
@@ -36,6 +36,7 @@
/*for/from play_title.c*/
#include <assert.h>
/* #include "config.h" */
+#include <inttypes.h>
#include <dvdread/dvd_reader.h>
#include <dvdread/ifo_types.h>
#include <dvdread/ifo_read.h>
@@ -61,8 +62,12 @@
# endif
+#define off_t off64_t
+
#else /* Solaris */
+#define off_t __off64_t
+
/* ////////// *BSD ////////// */
#if ( defined( BSD ) && ( BSD >= 199306 ) )
@@ -170,8 +175,6 @@
#include "dvd.h"
-#define off_t __off64_t
-
void usage(char *);
--------------------------------------------------------------------------------------------------------------
From: Noah Maxwell <noah.maxwell@gmail.com>
To: Robos <robos@muon.de>
Subject: dvd_rip script on my website now
Hey Robo's! I hope all is well with you. Just wanted to let you know I
finally put my recent project script (dvd_rip.sh) on my website. It heavily
uses vobcopy, and Ive gotton it to the point where it works pretty well, so
I hope other people will find it useful as well. Please feel free to mirror
it if you think anyone else might want to check it out:
http://noahmaxwell.com/dvd/
Thanks!
-------------------------------------------------------------------------------------------------------------
CHECK
From: Dave Yeo <daveryeo@telus.net>
building vobcopy-1.0.2 on OS/2
>> Lots of errors due to __off64_t not being declared, I added
>> #if defined(__EMX__)
>> #define __off64_t __int64_t
>> #endif
>> to vobcopy.h
>> Then lots of errors like
>> vobcopy.c:1569: error: `O_LARGEFILE' undeclared (first use in this
>> function)
>> vobcopy.c:1569: error: (Each undeclared identifier is reported only
>> once
>> vobcopy.c:1569: error: for each function it appears in.)
>>
>> since large files don't need to be flagged here. Also files should be
>> opened in binary mode. I just removed the O_LARGEFILE flags though I'm
>> sure there is a better way.
>> Now I get this error which I don't know how to handle not being a
>> programmer.
>> c: In function `get_free_space':
>> vobcopy.c:1799: error: storage size of `buf1' isn't known
>> vobcopy.c: In function `get_used_space':
>> vobcopy.c:1843: error: storage size of `buf2' isn't known
>> make: *** [vobcopy.o] Error 1
>
>Well, it looks like some header file isn't included. In linux it's
>#include <sys/vfs.h> /* or <sys/statfs.h> */ (straight from the man-page).
>In there the size of statfs should be declared. Can you look into that?
>I just did a quick check on google but it looks like os/2 doesn't have that
>function... But that was only a very superficial look.
>Please take a look and if you find something get back to me.
sys/vfs.h and sys/statfs.h are just here for Linux compatibility and
just include sys/types.h and sys/mount.h.
sys/mount.h is where statfs is declared but no members called buf1 or
buf2.
This is basically a standard (Free)BSD header. You can look at it here
http://svn.netlabs.org/libc/browser/branches/libc-0.6/src/emx/include/sy
s/mount.h
--------------------------------------------------------------------------------------------------------------
CHECK
From: Richard Handel <handel.richard@googlemail.com>
Reply-To: richard@cbmc.co.uk
To: Robos <robos@muon.de>
Subject: Re: Vobcopy bug report
[-- Anhang #1 --]
[-- Typ: text/plain, Kodierung: 7bit, Gr3,3K --]
Hi Robos,
I think you're right - I looked around, can't find any library
function to do this. I've done an alternative fix, which is a patch to
dvd.c (attached) - this one is better (more efficient), but they both
work, so doesn't really matter.
Not sure about UTF-8, I assumed it was just an ascii space char which
has to be escaped in /etc/mtab (since a literal space would mean 'end
of path') - but I'm guessing, & I've not looked into it too deeply.
Cheers,
Richard
On 12/09/2007, Robos <robos@muon.de> wrote:
> On Mon, 10.09.07, Richard Handel <handel.richard@googlemail.com> wrote:
> > Hi,
>
> Hi richard,
>
> > Just to let you know I found a minor bug in vobcopy, when I was doing
> > a 'mirror copy'- it crashes when there is a space in the file name on
> > the DVD. This is because /etc/mtab escapes spaces (they appear as
> > '\040'), but opendir doesn't understand the name in that format.
> >
> > I've written a quick patch to vobcopy.c (diff attached for your info).
> > I've tested it and it works (I'm using Linux, FC7), but it's not a
> > proper fix, because:
> >
> > 1) maybe the fix should go in dvd.c, not vobcopy.c so it works for any
> > call to get_device_on_your_own().
> >
> > 2) maybe the path names in /etc/mtab can have other escape chars as
> > well as spaces.
> >
> > 3) There's probably a library function to 'unescape' a string, but I
> > don't know what it is.
> >
> > 4) There's already a loop in /get_device_on_your_own() which goes
> > through all the characters in the path - maybe it would be more
> > efficient to use that loop instead of creating a new one (but this
> > depends if there's a library function to strip out the escapes).
> >
> > I don't know enough about the above points to do a proper fix, but I
> > hope I've helped a bit if you decide you want to fix it properly.
>
> Huh, that's cool. I tripped about that myself 2 days ago. I don't know
> either if there is already a library that does the un-escaping/spacing, but
> I don't think so. I'll have a look at you patch and probably incorporate it,
> I was too lazy to fight too long with c since I'm already getting rusty
> again because of not using it that often :)
> BTW: I think this is some unicode/UTF-8 thing...
> Thanks a lot!
> Cheers
> Robos
>
> > Regards,
> >
> > Richard Handel
>
> > *** vobcopy.c.org 2007-09-10 16:03:42.000000000 +0100
> > --- vobcopy.c 2007-09-10 21:37:51.000000000 +0100
> > ***************
> > *** 803,808 ****
> > --- 803,816 ----
> > fprintf( stderr,"[Info] Writing files to this dir: %s\n", name );
> > }
> > //TODO: substitute with open_dir function
> > + /* START PATCH (Richard Handel, 10 Sept 07) unescape space characters in path */
> > + char* embedded_space = strstr(provided_input_dir, "\\040");
> > + while (embedded_space) {
> > + *embedded_space = ' ';
> > + strcpy(embedded_space + 1, embedded_space + 4);
> > + embedded_space = strstr(provided_input_dir, "\\040");
> > + }
> > + /* END PATCH (Richard Handel, 10 Sept 07) */
> > strcpy( video_ts_dir, provided_input_dir );
> > strcat( video_ts_dir, "video_ts"); /*it's either video_ts */
> > dir = opendir( video_ts_dir ); /*or VIDEO_TS*/
>
>
> --
> Robos -
> gpg --recv-keys --keyserver blackhole.pca.dfn.de 6EEADA09
>
>
[-- Anhang #2: dvd.patch --]
[-- Typ: text/x-patch, Kodierung: base64, Gr0,7K --]
*** dvd.c.org 2007-09-13 00:57:34.000000000 +0100
--- dvd.c 2007-09-13 00:56:43.000000000 +0100
***************
*** 524,532 ****
while(isgraph( (int) *(k) ))
{
! path[l] = *(k);
! k++;
! l++;
}
path[l] = '\0';
--- 524,534 ----
while(isgraph( (int) *(k) ))
{
! if (!strncmp(k, "\\040", 4)) { // replace escaped ASCII space ...
! path[l++] = ' '; // ... with literal space
! k+=4;
! }
! else path[l++] = *(k++);
}
path[l] = '\0';
---------------------------------------------------------------------------------------------------------------------
Ismail D (0,2K) Security problem(s) in vobcopy wegen cve
--------------------------------------------------------------------------------------------------------------------
Bug#448319: opens /tmp/vobcopy.bla insecurely, symlink attack
Changed Bug title to `CVE-2007-5718 insecure temporary file handling' from `opens /tmp/vobcopy.bla insecurely, symlink attack'.
--------------------------------------------------------------------------------------------------------------------
From: Nico Golde <nion@debian.org>
To: Robos <robos@muon.de>
Subject: Re: security issue in vobcopy
X-GPG: 0x73647cff
X-RZG-AUTH: hvKiKtSHbeE0ghP2VIXOfz9FbKPIjAFDNRMtknfPuvqS60u3mcM1eRqaSnkWtRs=
X-RZG-CLASS-ID: mo07
[-- PGP Ausgabe folgt (aktuelle Zeit: So 02 Dez 2007 23:13:15 CET) --]
gpg: Signature made Di 06 Nov 2007 07:33:23 CET using DSA key ID 73647CFF
gpg: Unterschrift kann nicht geprwerden: Schlnicht gefunden
[-- Ende der PGP-Ausgabe --]
[-- Die folgenden Daten sind signiert --]
Hi Robos,
* Robos <robos@muon.de> [2007-11-06 07:20]:
> On Mon, 05.11.07, Nico Golde <nion@debian.org> wrote:
> > did you see
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=448319
> > which is a security issue in vobcopy.
> > Please read the following:
> > https://www.securecoding.cert.org/confluence/display/seccode/TMP30-C.+Temporary+files+must+created+with+unique+and+unpredictable+file+names
>
> Someone from another distribution already made me away that someone thinks
> this is a bug...
> I'll try to fix "the problem" soon.
Errm referring to your ironic tone you don't think this is
an issue but you are wrong, it is ;)
> Whom shall I contact with the new version?
The maintainers for the distributions. It would be nice
could contact me and Stephen Birch for Debian.
Kind regards
Nico
-----------------------------------------------------------------------------------------------------------------------
CHECK
Subject: Bug#451145: off-by-one error
Reply-To: Nico Golde <nion@debian.org>, 451145@bugs.debian.org
Resent-To: debian-bugs-dist@lists.debian.org
Resent-CC: Stephen Birch <sgbirch@imsmail.org>
X-Debian-PR-Message: report 451145
X-Debian-PR-Package: vobcopy
X-Debian-PR-Keywords: patch
X-Debian-PR-Source: vobcopy
From: Nico Golde <nion@debian.org>
To: submit@bugs.debian.org
X-GPG: 0x73647cff
X-RZG-Auth: hvKiKtSHbeE0ghP2VIXOfz9FbKPIjAFDNRMtknfPuvqS60u3mcM1eRL0GjYHz1Y=
X-RZG-Class-Id: mo07
X-PTS-Package: vobcopy
X-PTS-Keyword: bts
[-- PGP Ausgabe folgt (aktuelle Zeit: So 02 Dez 2007 23:14:21 CET) --]
gpg: Signature made Di 13 Nov 2007 17:54:17 CET using DSA key ID 73647CFF
gpg: Unterschrift kann nicht geprwerden: Schlnicht gefunden
[-- Ende der PGP-Ausgabe --]
[-- Die folgenden Daten sind signiert --]
Package: vobcopy
Version: 0.5.14-2
Severity: normal
Tags: patch
Hi,
from vobcopy.c:
136 char dvd_path[255], logfile_name[20],logfile_path[255];
...
473 strncpy( logfile_path, optarg, 255 );
474 strcat( logfile_path, "/" );
This is an off-by-one. If optarg will consist of 255 characters strcat will write
ony byte past the stack.
The correct code would look like:
strncpy(logfile_path, optarg, sizeof(logfile_path)-1);
strcat(logfile_path, "/");
logfile_path[sizeof(logfile_path)-1] = '\0';
Kind regards
Nico
-----------------------------------------------------------------------------------------------------------------------
CHECK
Looking at the vobcopy source code it turns out that there
is a -L option to specify the logfile location, please add
this to the manual.
Kind regards
Nico
----------------------------------------------------------------------------------------------------------------------
From: Jimmy Moore <jimmy.moore@gmail.com>
To: Robos <robos@muon.de>
Subject: Re: Vobcopy
Hi Robos,
Here is the forum post about it (Check out last line):
http://www.usalug.org/phpBB2/viewtopic.php?t=9271&postdays=0&postorder=asc&&start=15&sid=7342fa91d35558b6782882b2ebab9000
Also from mplayer/mencoder manual:
http://www.mplayerhq.hu/DOCS/HTML/en/faq.html#id2540533
I had an idea to use vobcopy, then when it failed, use mencoder, but the
problem is that mencoder reads the whole title and combines everything into
a single VOB file :( whereas I want the files from the DVD exactly as they
were for menus etc.
It does seem that dvdnav does get around the problems with Sony protection,
which I believe is bad sectors or something. Also looks like dvdnav does all
that dvdread does now, perhaps including some extra stuff.
I've tried using 'ddrescue' to create an ISO image of the DVD, which it does
successfuly but with errors. I'm not sure if pointing vobcopy at that ISO
will work, but I may try that next
Let me know what you think :)
Regards
Jimmy
------------------------------------------------------------------------------------------------------------------
From: Louis Granboulan <Louis.Granboulan@ens.fr>
Subject: Re: vobcopy on MacOS 10.4
To: Udo 'Robos' Puetz <udo@muon.de>
>Well, sure, but I at least need a way to figure out which version I'm
>compiling on and #include and such accordingly.
I don't know how to find it simply within gcc.
Here is a rather dirty technique
#include <unistd.h>
#if !defined(_POSIX_ASYNCHRONOUS_IO)
/* MacOS 10.2 or before */
#elif _POSIX_VERSION == 198808L
/* MacOS 10.3 */
#else
/* MacOS 10.4 */
#endif
Louis
------------------------------------------------------------------------------
From: Thiemo Gehrke <tgehrke@reel-multimedia.com>
To: Robos <robos@muon.de>
Subject: bug in vobcopy 1.0.0
Hallo,
habe einen Bug gefunden:
gibt man -q als Parameter an und ist ein Verzeichnes mit gleichem Namen schon
vorhanden, schreibt vobcopy unentwegt
"[Hint] please choose [c]ontinue or [q]uit the next time ;-)"
in die /tmp/vobcopy.bla
Und zwar so lange, bis das Dateisystem voll ist.
Es fehlt also noch eine "always continue on error" option oder dergleichen.
ich hoffe, ich bin nicht der 357. der das berichtet...
gr
Thiemo
---------------------------------------------------------
From: "Jared P. Cordasco" <jcordasc@cs.stevens.edu>
To: robos@muon.de
Subject: vobcopy bug report
Reply-By: Oct 4 2005 12:00 -0500
[-- Anhang #1 --]
[-- Typ: text/plain, Kodierung: quoted-printable, Gr2,0K --]
Hi,
I ran into a problem with vobcopy recently and I haven't had the time to
poke around and send a patch with this bug report, but I could if you'd
like. The problem is that vobcopy cannot handle very large hard drives
for output. As you can see below I have such a drive, mostly free:
Filesystem Size Used Avail Use% Mounted on
/dev/hdb1 367G 50G 315G 14% /mnt/400
however running
# vobcopy -o /mnt/400/backups/ -m
yields:
Vobcopy 1.0.1 - GPL Copyright (c) 2001 - 2006 robos@muon.de
[Hint] All lines starting with "libdvdread:" are not from vobcopy but
from the libdvdread-library
[Info] Path to dvd: /dev/hdd
[Info] Name of the dvd: RABBI_JACOB
*** Zero check failed in ifo_read.c:432
for vmgi_mat->zero_3 = 0x00000000010000000000000000000000000000
[Info] There are 4 titles on this DVD.
[Info] There are 15 chapters on the dvd.
[Info] Most chapters has title 4 with 12 chapters.
[Info] All titles:
[Info] Title 1 has 1 chapter.
[Info] Title 2 has 1 chapter.
[Info] Title 3 has 1 chapter.
[Info] Title 4 has 12 chapters.
[Info] There are 4 angles on this dvd.
[Info] All titles:
[Info] Title 1 has 1 angle.
[Info] Title 2 has 1 angle.
[Info] Title 3 has 1 angle.
[Info] Title 4 has 1 angle.
[Info] DVD-name: RABBI_JACOB
[Info] Disk free: -2099069 MB
[Info] Vobs size: 3900 MB
[Error] Not enough free space on the destination dir. Please choose
another one or -f
[Error] or dirs behind -1, -2 ... are NOT allowed with -m!
However, when I append '-v -v' to get the log file, the log file is
*different* than the above output in that it shows free disk space as
0MB. I've attached that log file.
If you want, I'll poke around and send you a patch as I'm sure its
simple enough to fix. Just let me know.
-----------------------------------------------------------
From: Keith Brings <ceo@noizu.biz>
Reply-To: ceo@noizu.biz
To: robos@muon.de
Subject: vobcopy quirks / and fixes.
I just finished modifying your source to get everything to run on solaris express build 60 64bit.
I only had to make a few minor tweaks but making a note of them might help simplify install for someone even newer to the *nix world than me.0
Make file:
1. On your make file the deb: entry stops the make with a "unexpected end of line" error. I just took the deb: section out and make ran find.
2. CC =? gcc also produced a crash, I'm not sure of the scripting syntax or what this was suppose to do but CC = gcc, or CC = cc works fine.
source code.
3. dvd.c & vobcopy.c require #include <stdint.h? before calling vobcopy.h (before calling dvd-read's headers)
4. dvd.c get_dvd_name() was killing the program and calling a segmentation_failed core dump.
I suspect that solaris/intel treats dvd devices differently than solaris/sparc. Any who the dvd name isnt in the device name but just removing the #if defined( __sun ) line and using the non
+__sun version of the function worked fine.
5. __off64_t
I may just have compiler set-up issues but
#define off_t __off64_t in vobcopy.h was flagged later on as undefined.
replacing that line with #define off_t off64_t worked fine.
I'm sorry I cant be more helpful on why these fixes worked for me, i'm new to linux and especially linux programming but, hopefully they help.
And feel free to give me some favorable mention if they do help. ^-^ minute changes though they be.
- Sincerly,
Keith Noizu
--------------------------------------------------------------------------------------------------------------
|
