-
Notifications
You must be signed in to change notification settings - Fork 44
/
ChangeLog
6502 lines (4013 loc) · 146 KB
/
ChangeLog
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
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
2010-10-22 12:08 omsynge
* ChangeLog: Updating Chnage log
2010-10-22 11:58 omsynge
* src/Makefile.am: dcap header reorganization missed adding header
files to Makefile.am
The build target "make dist" no longer contained all the header
files required to build dcap.
This caused the build target "make rpm" to fail.
http://svn.dcache.org/build/job/dcapBuildPackage_VDT_x64_SL_5.4_trunk/4/console
With this patch, the target "make rpm" now works.
Signed-off-by: Paul
Patch: http://rb.dcache.org/r/2568/
2010-10-21 15:31 pmillar
* src/Makefile.am, src/dcap_close.c, src/dcap_lcb.c,
src/dcap_lcb.h, src/dcap_open.c, src/dcap_read.c,
src/dcap_types.h: dcap: add initial support for local caching
(dcap++)
This patch adds support for a simple LRU cache: a Local Cache
Buffer (LCB).
It is a reworked version of the patch from Guenter Duckeck
<[email protected]>. When reworking it, I've
tried to make
the algorithm more readable by splitting the functionality into
separate
functions. I've also removed code-duplication (as much as
possible), those
variables and structure members that weren't actually used, all
the commented-out
code and the (logical) dead-code.
I've tried to fix some of the issues Gerd raised in his initial
review; however,
some of these issues, whilst certainly valid, may not be worth
fixing here.
Instead, we can address them with a rewrite of dcap so it has a
generic caching
layer (as Tigran proposes).
I've copied Gerd's comments that are still outstanding into the
code as comments
prefixed with "REVISIT".
I'm aware of a number of limitations with the code as-is:
a) the first cache block (block-number 0) must always be cached,
b) the algorithm is O(n), where n is the number of blocks,
c) behaviour under error conditions [either dc_real_read() fails
returning -1 or it read fewer bytes than requested when not
at EOF] is poor.
d) the code disables read-ahead (RA) which, I believe isn't
necessary.
Current implementation of LCB+RA is suboptimal, but should be
functional.
e) if LCB+RA is not allowed, then client code can subvert this
by explicit call to dc_setBufferSize().
Patch: http://rb.dcache.org/r/2475/
Target: trunk
Acked-by: Gerd
Acked-by: Tigran
Acked-by: Owen
2010-10-18 08:45 pmillar
* src/dcap_test.c: dcap: update test program
The program dcap_test provides a basis for testing the dcap
library. It uses a
specially formatted file, creating it if necessary, where the
file contains offset
information stored as 4-byte integer values. This allows the test
to verify the
contents of the data when reading.
The patch alters the format of the data in two ways:
1) the byte-order of the integers is fixed to be
network-byte-order. Previously it was host byte-order,
which lead to ambiguity that had to be worked around.
2) the offset had a somewhat counter-intuitive meaning:
the offset recorded in the file is the offset of the
following byte.
After the patch, the integer value of a 4-byte sequence is the
offset of the first
of the four bytes. The first 32 bytes of the file are now:
00 00 00 00 00 00 00 04 00 00 00 08 00 00 00 0c
00 00 00 10 00 00 00 14 00 00 00 18 00 00 00 1c
The dcap_test program tests the ability to read data by
repeatedly reads a (fixed)
block of data and skipping forward a small, random amount until
the file is
exhausted. The data read is verified by checking it against the
expected values.
This patch enhances the tests. It decouples the access patterns
from the mechanism
for running the pattern. In addition to the existing access
pattern (now called
"walking forward"), the patch introduces additional
access-patterns: "walking
forward with random initial offset", "walking backward", "random
4-byte reads" and
"random block reads".
The patch includes one "runner" that implements a round-robin
selection of the
selected access patterns. Any number of access patterns may be
given. This allows
multiple patterns to be stacked; for example, "walking forward" +
"walking backward"
gives a cross-like access pattern.
The access-patterns are written to externalise their state, so
multiple instances of
the same access-pattern may be used by a runner. Combining two
"walking forward
with random initial offset" simulates the ATLAS ROOT access
pattern.
The round-robin runner has a selectable terminate conditions.
There are three
possible termination conditions: after the first access-pattern
completes, after the
last access-pattern completes, or after a fixed number of
iterations. If an
access-pattern terminates before the runner terminate condition
then that
access-pattern is disabled and the runner will continue with the
remaining
access-patterns.
Possible future work is described at the beginning of the file.
These include
adding a multithreaded runner, to test dcap when used by multiple
threads
concurrently; and adding support for testing multiple file
descriptors concurrently.
Patch: http://rb.dcache.org/r/2478/
Target: trunk
Acked-by: Owen
Acked-by: Tigran
2010-10-13 14:22 pmillar
* src/dcap_debug.h: dcap: fix compilation on Solaris
Patch committed as r.14673 broke compilation on Solaris. This
patch fixes this.
Patch: http://rb.dcache.org/r/2517
Acked-by: Owen
Target: trunk
2010-10-13 12:11 pmillar
* src/dcap_debug.c, src/dcap_debug.h: dcap: refactor dcap debugging
slightly
dcap library provides a debugging support where different
channels ("levels") of output
may selected.
This patch adds two additional methods: dc_vdebug and
dc_is_debug_level_enabled. Both
are exposed to other components within the dcap library but are
not listed as public
methods.
The dc_vdebug method is a var-args version of the dc_debug
method. This is similar to
the 'v' version of the printf family of functions (printf vs
vprintf, etc).
The dc_is_debug_level_enabled returns True (1) if the supplied
level is enabled, False
(0) if not. This is intended to allow external modules to avoid
work that will not be
used in generating output.
Patch: http://rb.dcache.org/r/2510/
Target: trunk
Acked-by: Gerd
2010-10-12 17:05 pmillar
* bootstrap.sh: Reverting commit 14671 as Solaris packaging is more
broken than I thought
2010-10-12 15:09 pmillar
* bootstrap.sh: dcap: fix bootstrap.sh to work on Solaris
Solaris packaging provides tools like aclocal and automake as
filenames with a
version-specific suffix (e.g., aclocal-1.11, automake-1.9, etc);
moreover, we cannot
necessarily mix-and-match. We must use tools with a consistent
version; for example,
running v1.11 of aclocal with automake.
The current implementation of bootstrap.sh simply invokes
"aclocal" and "automake"
without any version-specific suffix. This doesn't work on
Solaris. There is
commented-out lines in the current bootstrap.sh that include a
version-specific suffix,
suggesting this issue is known but not addressed.
This patch fixes the problem. It looks for a set of consistently
named tools with a
version-specific prefix, in decreasing version numbers (1.11,
then 1.10, then 1.9). If
these all fail, it tries again without any version-specific
suffix. If none of these
succeed then the script fails with a suitable error message.
The output (on the terminal) from running bootstrap.sh should be
identical to
previously. The behaviour on running bootstrap.sh should be
identical, including that
it terminates immediately after any failing step.
Patch: http://rb.dcache.org/r/2465/
Acked-by: Owen
Target: trunk
2010-10-07 14:27 pmillar
* src/Makefile.am: dcap: fix building on Solaris
A previous commit (committed as r14667) broke compilation on
Solaris machines when using the
Solaris compiler. This patch fixes that problem.
Target: trunk
Patch: http://rb.dcache.org/r/2487/
Acked-by: Owen
2010-10-07 13:33 pmillar
* src/Makefile.am, src/dccp.c, src/print_size.c, src/print_size.h,
src/sigfig.c, src/sigfig.h: dcap: add -H option to dccp that
provides feedback during transfer
Whilst in Karlsruhe for GridKa school, I was talking to someone
about their experience of dCache
being very slow when copying files into and from dCache via dccp.
The user was unable to answer
simple questions that might indicate what is the problem (where
you waiting for a mover? was the
checksum taking a long time? was the transfer slow on-average, or
did it "stutter"?). I released
that this information is currently difficult (or impossible) to
obtain with dccp. Moreover, without
any feedback during a transfer, one must have blind faith that
the transfer is proceeding.
This patch addresses this issue. It provides some feedback to the
user during a transfer. The
feedback uses the (old) method of writing output without the
line-feed character ('\n') but using the
carriage-return character ('\r') instead. Repeated use of such
output gives the user the impression
of a single line of text is being updated with new information.
Some care is needed to append spaces
to the end of the new version of the line if it has shrunk. This
is to hide character(s) from the
previous line.
The transfer feedback line contains a progress bar followed by
zero or more items. The items are:
percentage of file transferred, number of bytes transferred and
the average transfer rate. The code
determines the width (number of columns) of the terminal
dynamically and scales the output
accordingly. If the terminal has sufficient width then all items
are displayed and the bar is scaled
to take (almost) all of the line's remaining capacity. If the
width is too small to allow this then
items are progressively switched off to provide additional space,
allowing the progress bar to grow
in size. This continues until a minimum width of the progress bar
is achieved or all items are
switched off (whichever happens first).
The progress bar is a sequence of characters the first being the
open square-bracket and the last
being the close square-bracket. Those in between are either a
dash ('-') or a hash ('#') and form
the part that indicates the transfer's progress.
If the size of the file being transferred is known in advance,
the progress bar is a "percentage
progress bar". This shows information as a sequence of zero or
more hash symbols followed by zero or
more dashes. The total number of symbols is fixed, for given a
progress bar size. The number of
hash- and dash- symbols is chosen to be proportional to the
amount of data written and still to write
respectively. The result is an ASCII-art version of the familiar
GUI progress-bar. It is also how
the rpm command shows progress.
The following is an example line when the file size is known and
the terminal is sufficiently wide to
allow all items:
[#######---------------------------------------------------------------]
11% 45.0 MiB (4.09 MiB/s)
If the size of the transfer isn't known in advance (e.g., data is
taken from stdin) then it is
impossible to show a "percentage activity bar". Instead, the
progress bar is an "activity progress
bar". This indicates bytes transferred as a shorter bar (made up
of some five hashes). This shorter
bar is initially left-most within the progress bar and "moves to
the right" as data is written. When
the shorter bar reaches the end of the activity bar, it wraps.
(This similar to how Firefox shows
progress under similar circumstances.)
The following is an example when the transfer size is unknown and
the terminal is sufficiently wide
to allow all items:
[-----#####----------------------------------------------------------------]
8.00 MiB (4.00 MiB/s)
In writing this support, I adding a function for formatting file
sizes using SI binary prefixes (kiB,
MiB, etc), taking care of aesthetics. The patch also updates the
final line of output (which gives a
summary of the transfer) to also use the new function.
The following is an example of current dccp's final output line:
417488294 bytes in 78 seconds (5226.97 KB/sec)
This is an example of final output line after patch:
417488294 bytes (398 MiB) in 76 seconds (5.24 MiB/s)
Current limitations and future work:
o no user feedback when the transfer stalls,
o could add an estimate of the time remaining until the transfer
finishes.
Target: trunk
Patch: http://rb.dcache.org/r/2400/
Acked-by: Gerd
Acked-by: Owen
2010-09-23 08:08 pmillar
* src/dcap_error.c: dcap: fix type casting of type-punning
In dcap_error.c, the support for thread-local variable,
t_getspecific macro,
which is a simple wrapper around pthread_getspecific(), is used
in dcap_error to
obtain a ptr to the thread-local errno. The dcap_error casts this
pointer to a
(void *), rather than (int *).
Assigning to a type-punning, like this, is not allowed by C89/C90
standard but
historically, compilers turn a blind eye to them.
It's legal to assign a (void *) point to any other kind of
pointer without
casting. The pthread_getspecific() function returns a (void *)
pointer, so the
explicit casts in dcap_error are actually unnecessary.
The proposed patch fixes the "dereferencing type-punned pointer
will break
strict-aliasing rules" warnings.
Patch: http://rb.dcache.org/r/2452/
Target: trunk
Acked-by: Gerd
2010-09-23 08:02 pmillar
* src/dccp.c: dcap: fix possible use of uninitialised variable
The copyfile method in dccp is responsible for copying the data
from source to
destination. This function allocates a buffer to hold an amount
of data. If
this allocation fails then the file size is not set and the
corresponding print
statements use an uninitialised value for the transferred size.
This patch fixes this by initialising size to zero.
Target: trunk
Patch: http://rb.dcache.org/r/2457/
Acked-by: Gerd
2010-09-23 07:59 pmillar
* src/dcap_dirent.c: dcap: remove unused function declared in
dcap_dirent
The char2dirent is not used anywhere in dcap code. This patch
removes it.
Patch: http://rb.dcache.org/r/2458/
Target: trunk
Acked-by: Gerd
2010-09-23 07:57 pmillar
* src/dcap_read.c: dcap: fix (void *) pointer arithmetic in
dcap_read
The buffer argument to dcap_real_read function is defined to be
(void *), i.e., a
pointer to some absolute location in memory.
However, the dcap_real_read implementation treats the buffer
pointer as if it
pointed to an array of bytes, which is natural. However, in doing
this, the code
increments the pointer as data is read. This doesn't make sense
for a (void *)
pointer, it only makes sense for a pointer to an array of some
type with
well-defined length.
This patch fixes this by accepting a (void *) pointer as an
argument but
assigning the value to a (char *) variable. This makes explicit
the semantics
currently only tacit in the code.
Patch: http://rb.dcache.org/r/2460/
Target: trunk
Acked-by: Gerd
2010-09-22 13:08 pmillar
* src/dcsuck.c: Silence compiler warning
gcc emits a warning about possible misunderstanding of
arithmetic bitwise operator precedence (AND has higher
precedence than OR). It suggests putting parentheses around the
term to make the logic explicit.
This patch follows the compilers advice.
Target: trunk
Patch: http://rb.dcache.org/r/2459
Acked-by: Tigran
2010-09-22 10:17 pmillar
* ., config, plugins, plugins/gssapi, plugins/ssl, plugins/telnet,
src: Teach SVN to ignore generated files.
Tigran, Owen and Gerd are all happy with this.
2010-09-21 12:29 pmillar
* src/io.c: dcap: remove two dead functions
The file io.c contains two functions "writeln" and "readln" that
are not used
anywhere in dcap. This patch removes them.
Target: trunk
Patch: http://rb.dcache.org/r/2445/
Acked-by: Owen
2010-09-21 12:27 pmillar
* src/dcap_write.c: dcap: fix dc_writev bug
The dc_writev function wraps the POSIX writev vector write (a.k.a
"gather write")
function. It loops over the vector and builds a complete buffer
that is sent to the
mover.
The loop depends on the variable iobuf_pos, which is incremented
when processing the
elements of the vector; however, iobuf_pos is not initialised to
zero so may take an
arbitrary value.
This patch fixes this by initialising iobuf_pos to zero.
Target: trunk
Patch: http://rb.dcache.org/r/2444/
Acked-by: Owen
2010-09-21 12:25 pmillar
* src/dcap_stream.c: dcap: fix bug in dc_fgets
The function dc_fgets is the dcap wrapper of the POSIX fgets. The
implementation
contains a bug: if the size argument is zero then the return
value depends on an
uninitialised variable: n. If the uninitialised value of n is
less than zero then
the function returns the wrong value.
The patch fixes this by initialising n to zero.
Patch: http://rb.dcache.org/r/2443/
Target: trunk
Acked-by: Owen
2010-09-21 12:22 pmillar
* src/dcap.c: dcap: fix hostname label initialisation
In dcap, if the hostname of the door did not resolve then the
logging would attempt
to record an uninitialised string.
This patch fixes this.
Target: trunk
Patch: http://rb.dcache.org/r/2441/
Acked-by: Owen
2010-09-21 12:20 pmillar
* src/dcap.c: dcap: ensure ConfirmationBlock is initialised before
replying
The compiler noticed that the ConfirmationBlock variable "reply"
is not completely
initialised in the error case.
This patch fixes this by initialising the structure to an
all-zeros state before
writing the code part.
Patch: http://rb.dcache.org/r/2440/
Acked-by: Owen
Target: trunk
2010-09-21 12:17 pmillar
* src/dcap.c: dcap: add missing return type in function declaration
A previous commit added a function declaration without including
the return-type of
the function; whilst technically legal, it is not good practice
and results in a
compiler warning.
This patch fixes this issue by adding the return-type for the
function.
Patch: http://rb.dcache.org/r/2439/
Target: trunk
Acked-by: Owen
2010-09-21 12:01 pmillar
* src/dcap_acl.c: dcap: fix Solaris building (second part)
The file debug_level.h has a dual purpose: it contains the
definitions of the
various debug levels and it also is the entry-point for the HAVE_
macros that the
autoconf system builds.
In future, these two purposes need to be separated; however, for
now, we fix the
compilation problem by accepting the dual-role of this file and
including it when we
need to know the value of the HAVE_ macros.
Patch: http://rb.dcache.org/r/2451
Acked-by: Tigran
Target: trunk
2010-09-21 10:31 pmillar
* src/dcap.h.in, src/dcap_preload.c: dcap: fix compilation on
Solaris
There were two problems when trying to compile dcap for Solaris
that a previous
patch introduced.
The first problem is trivial: the man-page for the stat(2)
command states that
sys/types.h, sys/stat.h and unistd.h must be included. However,
it doesn't state in
which header file struct stat is defined.
The dcap.h file includes function prototypes using struct stat.
It includes
sys/types.h, but not sys/stat.h. On GNU systems, including
sys/types.h is
sufficient for a definition of struct stat; however, on Solaris
machines sys/stat.h
must be included for the definition of struct stat.
The fix is to include sys/stat.h in dcap.h
The second problem is slightly more complex: on Solaris, the
stat(2), lstat(2) and
fstat(2) methods are defined, in the header sys/stat_impl.h, as
static local
functions. This means that each compiled object file will include
its own
implementation of the stat, lstat and fstat functions. These
implementations are
simply a wrapper around "x"-versions of the functions (_xstat,
_lxstat, _fxstat
respectively). The purpose is to encode a hard-coded version
number as an argument
to these methods as a backwards compatibility measure.
However, this means that, in dcap_preload.c, there are two
definitions for each of
the three stat-functions (stat, lstat, fstat). The first set of
definitions come
from sys/stat_impl.h and the second set comes from dcap_preload.c
itself. The
proposed solution is to move the definition of stat, lstat and
fstat into the
corresponding #else clause. This allows the "built-in" wrapper in
Solaris to
operate, mapping (for example) stat --> _xstat. The _xstat
implementation is
overloaded by dcap_preload.c, which will handle the request using
dcap's
implementation of stat.
Patch: http://rb.dcache.org/r/2449/
Target: trunk
Acked-by: Tigran
2010-09-20 17:01 pmillar
* src/dcap_poll.c: dcap: fix strict C90 compliance in dcap_poll.c
Strict C90 compliance requires that variable declaration and code
may not be mixed.
This is not true for dcap_poll.c
This patch fixes this.
Patch: http://rb.dcache.org/r/2442/
Target: trunk
Acked-by: Owen
2010-09-20 14:28 pmillar
* src/Makefile.am, src/array.c, src/br.c, src/char2crc.c,
src/char2crc.h, src/dcap.c, src/dcap.dsp, src/dcap_accept.c,
src/dcap_access.c, src/dcap_acl.c, src/dcap_ahead.c,
src/dcap_ahead.h, src/dcap_checksum.c, src/dcap_checksum.h,
src/dcap_chmod.c, src/dcap_chown.c, src/dcap_close.c,
src/dcap_close.h, src/dcap_command.c, src/dcap_debug.c,
src/dcap_debug.h, src/dcap_dirent.c, src/dcap_dup.c,
src/dcap_error.c, src/dcap_error.h, src/dcap_fsync.c,
src/dcap_fsync.h, src/dcap_functions.h, src/dcap_interpreter.c,
src/dcap_lib.dsp, src/dcap_lseek.c, src/dcap_lseek.h,
src/dcap_mkdir.c, src/dcap_mqueue.c, src/dcap_nodes.h,
src/dcap_open.c, src/dcap_poll.c, src/dcap_poll.h,
src/dcap_preload.c, src/dcap_preload64.c, src/dcap_protocol.c,
src/dcap_protocol.h, src/dcap_read.c, src/dcap_read.h,
src/dcap_reconnect.c, src/dcap_rename.c, src/dcap_shared.h,
src/dcap_signal.c, src/dcap_signal.h, src/dcap_stat.c,
src/dcap_stream.c, src/dcap_test.c, src/dcap_types.h,
src/dcap_unix2win.c, src/dcap_unix2win.h, src/dcap_unlink.c,
src/dcap_url-test.c, src/dcap_url.c, src/dcap_url.h,
src/dcap_version.c.in, src/dcap_win32.h, src/dcap_write.c,
src/dcap_write.h, src/dccp.c, src/dccp_linux_directio.c,
src/dcsuck.c, src/dispatcher.c, src/fnal_thread.c,
src/gettrace.c, src/gettrace.h, src/input_parser.c, src/io.c,
src/io.h, src/ioTunnel.h, src/lineparser.c, src/lineparser.h,
src/linux_trace.c, src/node_plays.c, src/node_plays.h,
src/parser.c, src/passive.c, src/passive.h, src/pnfs.c,
src/readv_test.c, src/socket_nio.c, src/stack_trace.h,
src/str2errno.h, src/string2stat.c, src/string2stat.h,
src/system_io.c, src/thread_test.c, src/trace_back.h,
src/tunnelManager.c, src/wdccp.c, src/win32_dlfcn.h,
src/win32_libdl.c, src/win32_libdl.h: dcap: rationalise header
file usage
Currently, dcap's code base has somewhat confused use of header
files and
prototypes.
The dcap.h file contains all public material (macros, prototypes,
etc).
This file doesn't #include any other files and is intended for
distribution
with the library.
Prototypes for non-public, shared functions are found one or more
of these
places:
o in the dcap_shared.h file (either directly or by this file's
#include of
additional header files),
o individual header files corresponding to the source file (e.g.,
functions
defined in dcap_foo.c are prototyped in dcap_foo.h),
o individual header files with dissimilar names (functions
defined in
dcap_foo.c are prototyped in dcap_bar.h),
o locally, in C files often just before they are used.
For some functions, the prototypes are duplicated (some dcap code
sees one
prototype others see a different prototype). Some functions are
declared in
files that don't have access to (can't "see") that function's
prototype.
Both practises leave open the risk that the function
implementation and code
calling the function have different idea of the function's
signature ...
something the compiler could issue a warning about.
Another issue with the current dcap code is with functions that
are only
used in the file that declares them. Most of these are declared
statically
(so the function's name isn't exposed to the linker). However
some
functions have been missed. These missed functions pollute the
function
namespace and make it harder to spot dead code.
Yet another issue is that some macros and constant were
duplicated: any
mismatch between the declarations would lead to
difficult-to-diagnose bugs.
This patch tries to rationalise the header file usage in dcap.
After the
patch ...
The dcap.h file contains all public material (as before),
Each C file has a corresponding header file with the .c replaced
with .h
(e.g., foo.c --> foo.h). The exception is for dcap.c. The
corresponding file cannot be called dcap.h since that file
already
exists; instead, dcap_functions.h is used instead.
All functions are prototyped in precisely one location. That
location
depends on how the function is used:
For functions that are not public and are used only in the
file that declares them, the prototype is near the beginning
of that file and is static (the actual declaration doesn't
have to be static).
For functions that are not public and are shared (used in a
file other than where the function is declared) the
prototype is in the corresponding header file (e.g.,
dcap_foo.h for functions declared in dcap_foo.c).
For functions that are public, the prototype is in the file
dcap.h.
All declarations of a function have access to that file's
(single)
prototype (e.g., via a #include). This allows the compiler to
emit a
warning if the declaration doesn't match the prototype.
Where it makes sense, the declaration of some structures has
moved to
the corresponding header file; for example, the declaration of
the
checksum structure is now in dcap_checksum.h. However, for now,
the
majority of the structures remain in dcap_types.h (may fix this
with
later patches).
Files that no longer have any content are deleted; in particular,
the dcap_shared.h file.
All include statements for dcap header files use the double-quote
form:
for example, #include "dcap_foo.h"
All system library includes use the angle-bracket form; for
example,
#include <stdlib.h>
All preprocessor define statements (declaring a macro or
constants) are
declared in precisely one location.
Acked-by: Gerd
Acked-by: Owen
Target: Trunk
Patch: http://rb.dcache.org/r/2380/
2010-09-17 12:55 omsynge
* src/dcap.c, src/dcap_open.c: dcap invalid parsing error catching
moved to later stage to unify as suggested by Charles.
Since the old error checking did not handle all cases of renaming
files or stat I have moved the error handling to where Charles
suggested.
Signed-off by: Tigran and Paul
http://rb.dcache.org/r/2431/
2010-09-16 15:38 omsynge
* configure.ac: bumping the version number
2010-09-16 15:26 omsynge
* src/dcap_open.c: dcap: name_invalid error throwing.
The characters '\n' and an un escaped '"' will cause errors for
dcap causing a protocol violation and the code hanging.
This code checks for invalid file names.
The code checks in two places, as it should not effect local file
system names.
Signed-off by: Tigran Mkrtchyan
http://rb.dcache.org/r/2426/
2010-09-16 13:18 omsynge
* src/dcap_open.c: removing accidentally commited code
2010-09-16 13:16 omsynge
* src/dcap.c, src/dcap_open.c: removing accidently commited debug
information
2010-09-16 12:42 omsynge
* src/dcap.c: dcap: copy and paste error on changes.
Fis to a clear error, which occurs on transfers without debugging
but not with debugging.
This fix is clearly needed, and fixing it fixes behavior without
debugging.
Signed-off by: Tigran Mkrtchyan
http://rb.dcache.org/r/2422/
2010-09-15 12:11 omsynge
* src/dcap.c, src/dcap_str_util.c: dcap:Simple logic error when not
having to increase string length.
the buffers are being swapped so that the output buffer can be
re-used as an input buffer for subsequent calls to this routine.
The old code only did this when the allocation buffer was growing
larger.
Signed-off by: Paul
http://rb.dcache.org/r/2414/
2010-09-13 16:11 omsynge
* src/dcap.c, src/dcap_str_util.c, src/dcap_str_util.h: dcap :
memory issues Protection against message truncation
Charles Waldman was getting messages of character lengths in the
region of 3220. Along with messages from dcache saying missing
parameters.
http://rt.dcache.org/Ticket/Display.html?id=5774
I looked at the previous patch, http://rb.dcache.org/r/2027 which
addressed the issue of over running the buffer, but did not solve
the message truncation issue. This patch solves both the issues
solved in http://rb.dcache.org/r/2027
Like the previous patch I based this one on the error handling
from the man page from snprintf, I also solve the issue that the
C language specification says that the, for s*printf family of
functions, the output buffer must not overlap with the inputs. If
they do the result is undefined.
Signed-off by: Paul and Tigran
http://rb.dcache.org/r/2356/
2010-09-10 16:00 omsynge
* dcap.spec.in: mock dcap build issue adding BuildRequires:
zlib-devel to rpm and srpm
is needed to make "mock" work correctly, Brian Bockelman is using
"mock" to build dcap for OSG.
Signed-off by: Tigran
http://rb.dcache.org/r/2399/
2010-09-03 15:01 pmillar
* src/win32_dlfcn.h: Whitespace-only change: convert DOS ^M^J line
endings to unix-style ^J
2010-09-03 14:58 pmillar
* src/win32_libdl.c: Whitespace-only change: convert DOS ^M^J line
endings to unix-style ^J
2010-09-03 09:00 pmillar
* src/dcap_unix2win.c: Whitespace-only change: convert DOS ^M^J
line endings to unix-style ^J
2010-09-03 07:08 pmillar
* src/currentThread.c: dcap: remove file and function that isn't
used anywhere
The file currentThread.c contains a single function that isn't
used anywhere. The file itself isn't
compiled.
Patch: http://rb.dcache.org/r/2370/
Target: trunk
Acked-by: Tigran Mkrtchyan
2010-09-01 10:27 omsynge
* AUTHORS, COPYING, ChangeLog, INSTALL, Makefile.am, README,
configure.ac, dcap.spec.in: dcap packaging fixes, some files
where removed preventing rpm build succeeding.
Add some basic documentation to fix lack of rpm build, maybe the
error handling patches shoudl be removed but wanted to store them
some where safe,
rpm building now works again.
Signed-off by: Paul and Tigran
http://rb.dcache.org/r/2311
2010-08-30 13:59 pmillar
* src/Makefile.am, src/dcap.c, src/dcap_poll.c,
src/dcap_str_util.c, src/dcap_str_util.h, src/dcap_url.c,
src/dccp.c, src/dcsuck.c: Ticket #5690:
http://rt.dcache.org/Ticket/Display.html?id=5690
describes how dcap library has code of the form:
sprintf(s, "%s ...", s, ...);
Ostensibly, this code will append some text to the end of s;
however, the code
is broken. The C language specification says that the, for
s*printf family of
functions, the output buffer must not overlap with the inputs. If
they do the
result is undefined.
For many platforms, the above construct would work as expected:
the string s