<prev [index] next>

RendView Manual -- The Task Sources

Basic operation

As you already know, there are currently two task sources: The local task source using files on your local hard drive and the LDR task source effectively implementing the LDR client and all the network communications needed for LDR on the client side.
For a running RendView process, the task source generates tasks which are fed into the taskmanager to get them processed. Finally, the taskmanager gives the tasks back to the task source with success/failure info attached.

The local task source

The local task source is one of the most important parts. If you ever intend to have a frame rendered or filtered, you have to tell the local task source (LDR server or normal RendView) about that. The local task source saves several parameters about the frames to be rendered/filtered such as the file size, additional arguments to be passed to the render/filter process etc. These parameters may vary between different frames. This is the reason why I introduces per-frame blocks (see below).

Okay, before looking at the per-frame blocks and at the parameters, first some words about what the local task source does:
Normally, the local task source checks for the existance of the frame input file (e.g. POV file for rendering (or rendering and filtering) or some image file when only filtering). If the file does not exist, an error occurs.
If you specify -l-cont, you switch on continuing. This means that RendView additionally checks the time stamp: If the input file is newer than the output file, the frame is re-rendered (and also re-filtered if requested), otherwise it is skipped. Also, the modification time of additional files is checked and files are re-processed in case one of the additional files got modified (unless you switch that off using -no-l-add-check-mtime).
(Note: If input and output files have equal time stamps, input is considered to be modified.)
If you specify -l-rcont together with -l-cont, you tell RendView to switch on resume operation. (Note that -l-rcont without -l-cont has no effect.) Resume operation is only implemented for rendering and means that when RendView kills a render job (because of user request using SIGTERM or two SIGINT or because of a timeout) and the render job leaves an unfinished frame, this frame is kept and renamed appending the suffix -unfinished. When you launch RendView again it will check if an unfinished frame exists, check the timestamp and then will tell the renderer to resume the unfinished frame (or completely re-render it if the timestamp demands that). Once the file is completely rendered, the -unfinished suffix is removed. (In fact it is removed before resuming rendering.)
In case a job is not completely successful and you do not pass -l-rcont, the output file is deleted.
The local task source also deletes an existing output file if it comes to the conclusion that the frame has to be re-rendered/filtered. This means that you can safely symlink render/filter output files because the symlink will be removed before the task is fed into the task manager.
PLEASE NOTE one problem with POVRay: If you run more than one POVRay process on your box and you are using POVRay's clock value with the same input file (say, sceneA.pov), then you can run into trouble with -rcont. This is due to POVRay using a temporary file when resuming which gets named sceneA.tpn in this case. Hence, both unfinished frames (say frameA-00017.png and frameA-00018.png) are temporarily written into sceneA.tpn which simply produces garbage or even worse: confuses that POVRay process which was started lateron.
But note that this problem does neither appear if you are using separate frame files (e.g. frameA-00000.pov, frameA-00001.pov, etc.) nor if you are only using one POVRay process at a time (i.e. each LDR client runs with -ld-njobs=1).

Per-frame blocks

A lot of parameters can be specified on a per-frame basis, i.e. you can set them differently for different frames. I was looking for a nice way of doing that and came up with a simple but powerful method: frame ranges. It simply means that you can set the parameters for a range of frames by specifying the start frame number and the number of frames (that follow). (This is useful, because when making animations it is just natural that ranges of frames appear which need similar parameters.) There are a number of parameters which can be specified on a per-frame basis using per-frame blocks (see further down).

Per-frame blocks work in the following way: There is one per-frame block called the master frame block. This block stretches over all frames to be processed and only provides a set of default parameters in case no other per-frame block covers that parameter for a particular frame. You can set parameters for the master frame block by simply using e.g. -l-rd=povray3.5 or -l-r-fc.

If you need different parameters for some frames, say for example the frames 30...49, then you use a per-frame block beginning at frame 30 and being 20 frames long, e.g. -l-30:20-rd=povray3.1g or -l-30:20-r-fc (or -no-l-30:20-r-fc).
Whenever you specify a previously unknown frame range using -l-F0:N-whatever, RendView interally allocates a new per-frame block which collects all parameters specified for this frame range.
After argument processing is done, overlapping blocks are splitted and parameters merged. This works in the following way:
Say, two frame blocks A and B overlap. Then they are split into no more than 3 blocks, A, A+B, B, where A and B stay untouched while A+B gets all the parameters specified for A and B. In case A and B have different parameters (e.g. A uses renderer povray3.1 while B uses povray3.5), an override error occurs.

Note that in a per-frame block you only have to specify those parameters which differ from the master frame block. Because after merging/splitting the per-frame blocks, all the not yet set parameters get filled in from the master frame block. (This actually makes parameter merging at frame split time useful.)
Note also that you can use -l-r-30:20-r-files+=extra_file.png in case the per-frame block 30:20 needs all additonal render files as specified in the master frame block but additionally the file extra_file.png. This also works for additional arguments -l-r-args (and the same for the filter part).
Finally, note that RendView throws away unneeded per-frame blocks. Per-frame blocks are not needed if they have length 0 or if the master start and end frame (see -l-startframe, -l-nframes) will do not overlap with the frame range of the per-frame block. E.g. if you specify -l-nframes=0, then all per-frame blocks will be thrown away (as no frames will be processed at all).
Actually, RendView also deletes per-frame blocks which have the same content as the master.

An example for per-frame blocks

Consider the following example: (Note that you can use the advanced cmd line passing using -section-{...-} as described in the database section.)
-l-rd=povray3.5 -l-size=320x240 -l-r-args="-J"
-l-30:20-{ -rd=povray3.1g -size=640x480 -fd=shrinkfilter -f-args="-factor 2" -}
Then, all frames will be rendered passing the additional argument "-J" to the renderer; frames 30..49 will be rendered with povray3.1g at a size of 640x480 and have the shrinkfilter applied which gets the additional arguments -factor 2 passed (of course, you have to supply the shrinkfilter and an appropriate filter desc e.g. in the filters.par file). Additionally, POVRay gets the anti-aliasing argument +A0.3 passed for the frames 40..54 (additionally to -J). All other frames get rendered with povray3.5 at a size of 320x240 and not filtered at all.
You can control these settings by having a look at the verbose output right after starting RendView.
Note: Do not pass -l-nframes=0 here because that will make RendView throw away all the per-frame blocks as they are not needed! If you just want to see the output without having any frames rendered, you can pass -opmode=ldrserver without specifying any clients and then RendView will exit with an error right after dumping the local task source's info.
The output will look something like that in the above example:
Local task source: jump: 1; nframes: [unlimited]; startframe: 0
  Continuing: no
  Master frame info (complete dump):
    Renderer: povray3.5 (povray driver); output format: PNG (8 bpc)
      Size: 320x240; cont operation: resume (-rcont)
      Render dir: [cwd]
      Render timeout: [none]
      Clock value: [none]
      Add args: -J
      Add files: [none]
    Filter: [not filtering]
      Filter dir: [cwd]
      Filter timeout: [none]
      Add args: [none]
      Add files: [none]
    Frame patterns: render: "f%07d.pov" -> "f%07d.png"
                    filter: ... -> "f%07d-f.png"
  Frame info difference for frames 30--39 (10 frames):
    Renderer: povray3.1g (povray driver); output format: PNG (8 bpc)
      Size: 640x480; cont operation: resume (-rcont)
    Filter: shrinkfilter (generic driver)
      Add args: -factor 2
  Frame info difference for frames 40--49 (10 frames):
    Renderer: povray3.1g (povray driver); output format: PNG (8 bpc)
      Size: 640x480; cont operation: resume (-rcont)
      Add args: -J +A0.3
    Filter: shrinkfilter (generic driver)
      Add args: -factor 2
  Frame info difference for frames 50--54 (5 frames):
      Add render args: -J +A0.3
(The complete call to RendView was: rendview -rdfile=/path/to/my-renderers.par -fdfile=/path/to/my-filters.par -l-rd=povray3.5 -l-size=320x240 -l-r-args="-J" -l-30:20-{ -rd=povray3.1g -size=640x480 -fd=shrinkfilter -f-args="-factor 2" -} -l-40:15-r-args+="+A0.3")

You see how the frame splitting and parameter merging worked as well as how to use the defaults from the master per-frame block.
For a complete list of supported parameters, see below.

Parameters understood by the local task source

The local task source understands quite a lot of parameters. Here are the parameters which are global and not part of a per-frame block:

-l-fjump=NUM   (also: -l-j)
Only process every NUMth frame, use negative values to process last frames first. [FIXME: MORE INFO]
Default: +1
-l-nframes=NUM   (also: -l-n)
Specify the number of frames to be rendered. If not specified, this is autodetected: In case -l-fjump is positive, RendView simply processes frames until three frame input files in sequence do not exist. If -l-fjump is negative, the task source checks the input file existence and stops at the first non-existing frame file; the previous file is then considered the last file.
You may supply a value of 0 if you just want to get all the verbose output dumping startup info. The LDR server will connect to at least one client and then disconnect immediately.
-l-startframe=NUM   (also: -l-f0)
Start with frame numbered NUM instead of frame 0.
Switch on continuing. This means that frames are only rendered/filtered if needed based on modification timestamp (source/input versus destination/output file). The additional files are all treated as "source files" and therefore also checked when deciding whether to re-render/filter a frame (unless disabled, see -l-add-check-mtime below).
See also the info above.
Default: disabled.
-l-add-check-mtime   (also: -l-acmt)
If disabled (-no-l-add-check-mtime), RendView will not check the modification time of additional files when deciding whether to re-render/filter a frame.
Meaningless if -l-cont is not set.
Default: enabled
This is something like -schedule-delay and tells the local task source to not answer any request faster than MSEC milliseconds. This is mainly useful in debugging.
Default: 0, of course.
The following parameters can be specified on a per-frame basis, i.e. using per-frame blocks. As mentioned above, there exists a master per-frame block whose parameters can be set using e.g. -l-rd or -l-size. The parameters of a per-frame block which shall only apply to several frames (as opposed to the master) is specified using e.g. -l-3:8-rd or -l-3:8-size which means that this per-frame block begins at frame 3 and is 8 frames long.

-l-size=WWWxHHH   (also: -l-s)
Size of the rendered frame (and thus normally also of the filtered frame but that is not necessary).
Default: -l-size=320x240
Render output image format. Use -list-imgfmt to get a list of known image formats. You may only specify formats which are known to the used renderer and render driver.
Default is PNG (8 bits per color channel).
-l-renderer, -l-filter=DESC_NAME   (also: -l-rd, -l-fd)
Specify the render/filter desc to use. You may use the special value none to switch off rendering/filtering of the frames in question.
Default: none
Enable render resume operation (if the renderer supports it like POVRay does). This means that unfinished frames can be resumed. See above for more info.
Note: This option requires -l-cont in order to work.
You can use -no-l-cont to explicitly switch it off.
Default: enabled if the renderer supports it.
-l-r-args, -l-f-args=ARGS
Space-separated list of additional command line args to be passed to the render/filter process. Use quotes (") if you need to pass args with spaces or protect the spaces with a backslash. If you want to include quotes or backslashes, you need to protect those using a backslash, too. Also note that the shell tends to interprete such characters, so best put all the option in single quotes (which get removed by the shell).
-l-r-files, -l-f-files=FILES
Space-separated list of additional files needed for the rendering or filtering. This is not needed for plain RendView operation but probably for LDR because these additional files probably have to be transferred to the client.
Path is relative to RendView's CWD (current working directory).
Please read the notes about the flat directory structure (above) as well as the current limitation (no file may appear in both -l-r-files as well as -l-f-files).
-l-r-timeout, -l-f-timeout=SEC
Specify a render/filter timeout, i.e. the time limit for the render and filter process to finish. You can pass a similar timeout using the task driver interface (e.g. -ld-r-timeout) and the shorter of the two timeouts will take effect.
Use a value of -1 to disable. Default: no timeout (disabled)
-l-r-frameclock   (also: -l-r-fc)
Switch on/off (using -l-r-fc/-no-l-r-fc) use of the frame clock value as supported by POVRay (POVRay's native animation support using POVRay options +SFFRAME and +EFFRAME to select the frame to render).
NOTE: How it is meant to work:
If you do not use the frame clock, disable this option (default). You may pass any +Kxy options to POVRay (as additional args or in an .ini file) without effect because RendView automatically appends +KFI0 +KFF0 at the end of the command line to make sure that the frame clock is disabled.
If you do use the frame clock, enable this option. Make sure to pass correct values for +KFI, +KFF, KI, KF either using additional args (-l-r-args) or by using an .ini file (see -l-r-ifpattern below). RendView will then simply pass the frame number of the frame being rendered using +SFFRAME +EFFRAME so that POVRay will automatically calculate the correct clock value from the SF/EF option and the K-options provided by the user. RendView will automatically pass +KFI0 as first cmd line arg because RendView defaults to begin animations at frame 0 (you can override that using .ini file settings or additional args for POVRay.
See also -l-r-ifpattern below.
Default: disabled.
Example on the quickstart page.
The frame clock support works the way as described above sinve version 0.7.0. The options -l-r-fcstart and -l-r-fcstep (-l-fc0, -l-fcdt) as provided by earlier versions were dropped in favour of this more flexible and easier to use solution.
This tells RendView in ocal operation to change into this directory before calling the renderer. Therefore, -l-r-ifpattern and -l-r-ofpattern (see below) are considered relative to DIR.
Default: current directory.
RendView will change into this directory before executing a filter program. Hence, -l-f-ofpattern (see below) is considered relative to -l-f-dir.
Default: current directory.
-l-r-ifpattern, -l-r-ofpattern, -l-f-ofpattern=PAT
Render frame input, render frame output and filter frame output patterns, respectively. Note that the render frame output pattern is automatically the filter frame input pattern and hence only one option is provided.
PAT is a frame pattern, i.e. essentially a file name with a %d-spec to be replaced by the frame number.
The path is relative to the job's working dir (i.e. relative to -l-r-dir for -l-r-ifpattern and -l-r-ofpattern as well as to -l-f-dir for -l-f-ofpattern).
The -l-r-ifpattern does not have to contain a %d-spec (e.g. if you are animating using the frame clock); the other two options must include a %d-spec.
The %d-spec follows standard printf(3) rules, you may use:
%d to get decimal formatting
%x to have the frame number formatted hexadecimal
%X for hex with capital letters
%03d (for example) to get 000,001,002,003, etc. (i.e. 3 digits with leading zero)
Note: The render input frame pattern needs an extension (like .pov); the output patterns get one added automatically depending on the output image format (-l-oformat, see above).
Example: -l-f-ofpattern=frame-%03d-filtered
Default: -l-r-ifpattern=f%07d.pov
The render output pattern defaults to the render input pattern with the extension removed and replaced by the image format's extension (as well as an added frame number %d-spec in case the input pattern lacks such a apec).
The filter output pattern defaults to the render output pattern with a -f added before the file name extension (meaning "filtered").
POVRay note: Using POVRay, you may also pass an .ini file as frame pattern (with %d-spec or without when using the frame clock). If the input file name ends in ".ini", the POVRay driver passes it to POVRay without the +I prefix and POVRay will read it as ini file. Make sure to add a +IFILE in the .ini to tell POVRay about the input file and pass the FILE as additional file using -l-r-files.
Example on the quickstart page.

The LDR client

Finally, some more words about the LDR client. As mentioned before, LDR is a client server system with the rules swapped in some way: The LDR client runs on all computers which shall do the actual rendering/filtering and listen on some port. The LDR server gets launched by you if you have work to be done, and connects to all the clients in order to supply the tasks, required files and get success/failure info and processed frames back. When all tasks are done, client and server disconnect and the client waits again (after "recovery") for a server connection in order to begin a new work cycle. (The work cycle count is transferred to the server upon connect and can be read in verbose output together with the current load of the client box.)

Only one server can connect to a client at any time. The data link between client and server is exactly one TCP/IP connection. All data, tasks, requests and responses go over this single connection which is driven in full duplex mode (i.e. the client can download a file and then receive a new task while simultaniously uploading a different file). This sort of "pipelining" made the LDR client and server harder to implement.
There is no way for the LDR client to disconnect from the server while it is working because both the client and the server must be able to send data (commands, info) to each other at any time during work.

Of course, there are various timeouts, especially on the server side as well as on the client side (see taskmanager and below) which make sure that dead clients / servers are detected. The server can also try to re-connect to lost clients.

This requires some sort of authentication on the client side. Otherwise, anybody could use an LDR server and connect to your clients letting them to his work. The auth works as follows: You may specify a password when starting the LDR client. Only servers which know the password are allowed to connect to the client. (Hence, you also have to specify the password when starting the server.)
As no encryption is used for the LDR connection (unnecessary overhead), a challenge-response authentication applying the SHA (hash) algorithm: The client reads some challenge data from /dev/urandom (or, if /dev/urandom is not available, produces the challenge data using a time-seeded standard PRNG which may be insecure!) and sends it to server. The server computes the SHA hash value of the challenge and the password and sends it back as response. The client compares the response with the expected response and rejects the server if they do not match.
Furthermore there is an address-based authentication: The client will only allow servers which connect from one of the allowed networks (IP addresses; parameter -L-servernet).

The client has to download all the files required by the actual rendering/filtering. Hence, you must tell the (local) task source on the server side about all required files. Of course, the main frame input file is needed but you may specify any number of additional files (using -l-r-files and -l-f-files). The client will normally only download the additional files once and even keep them between several work cycles. However, it will download files again if they change their time stamp (i.e. if the modification time on the server is newer than the modification time of the copy on the client side) or file size so that it keeps up to date while at the same time saving network bandwidth. You can control that using -L-r-delin and similar options (below).
Note that this does not require that the time on all computers is synchronisized: RendView is doing automatic client/server time correction by calculating the maximum time difference upon connect (watch verbose output) and applies the difference to timestamp tests (unless disabled via -no-L-time-correction).
Note that resume operation also works with LDR, which means that incompletely rendered frames are down- and uploaded if you specify render resume (-l-cont -l-rcont).

Please note that the LDR client uses a flat directory structure which means that all files are put into the same directory. This also means that you have to design your frame input files (frame00.pov, scene.pov) in a way that they cope with this situation. (Due to POVRay's include path this is normally no problem.) The reason for this is that I consider it too dangerous to let the server specify directories as well as file names. If people desperately need that feature, I may consider implementing it.

Please also note a current limitation: An additional render file (additional file used for rendering, e.g. heightfield_data.png) cannot be an additional filter file and vice versa. If you really need the same additional file for rendering and filtering, use a symlink. Unfortunately, they will then be transferred twice.

Running the LDR client in shared directories (like NFS)

RendView's LDR client, by default, will transfer all required files using the internal data transfer as implemented in LDR. RendView uses time stamp and file size checks to determine if a file has to be downloaded. However, when using several LDR clients on different computers on an NFS shared volume, this is not what you want because RendView will then (by default) attempt to overwrite the files with themselves leading to trouble (this is because exactly matching time stamps on client and server trigger downloading the file once by default).
So, when using shared directories (even when running an LDR client on the same box as the LDR server and from the same directory) requires passing some extra option: -L-transfer=all- (and don't forget the dash at the end!)
As LDR uses a flat directory structure (for security reasons), this requires the shared directory to provide just that flat dir structure as expected by the LDR client (i.e. put all files into the same (shared) directory and start the LDR client from within this directory).
Of course, you can use a heterogenous setup with 15 clients sharing an NFS volume with the server and further 10 clients using LDR to transfer all files (-L-transfer=all+ [default] for those).
Note: I am unsure if race conditions can make your life uneasy when using NFS.

Parameters understood by the LDR task source

Specifies the port the LDR client listens at.
Default: 3104
Set the client password. PASS can either be a the actual password string or one of the following special values:
none: use no password (insecure); same as if you do not specify one
prompt: asks you to enter a password upon start using getpass(3)
file:PATH: read password from file PATH No more than 128 bytes will be read; falls back to prompt if an error occurs or the file is empty.
Please also read the note about passwords in the taskmanager chapter.
This specifies a list of IPv4 addresses (client addresses or network addresses). If specified, only servers which match one of the addresses are allowed to connect. SNET is a list of space-separated server nets. A server net spec is either simply an address or host name (e.g. localhost or or an address or host name with a network bit spec (e.g. localhost/8,
Normally, a network address has all the less significant bits set to 0 (e.g. the last 8 ones when using "/24"). If that is not the case, a warning is written and the corresponding network address is used. Hence, it is possible to write myhost/24 if you want to allow all clients in the locat 8 bit subnet in which myhost is.
If you do not specify a server net, any source address is accepted (default).
This option tells the LDR client to create the directory DIR and change into it upon startup. All the temporary files will be placed in that directory and the renderer/filter will be launched with it as cwd.
If you do not specify DIR, then RendView will create one itself with the name /tmp/ldrclient-pid (with pid being the PID of the LDR client process).
RendView will automatically delete the directory when exiting. By default, this feature is swiched off and the current directory is used.
The server sends ping control commands to the client in some time interval (see -Ld-keepalive in taskmanager docu). The time interval is transferred from the server to the client upon connect, so the client knows that it has to expect a ping every -Ld-keepalive seconds. Consequently, the client will consider the server as dead when no ping arrives within -Ld-keepalive multiplied with NUM divided by&nsbp;10. E.g. if the keepalive time is 30 seconds and NUM is 25, then the client will expect pings every 30*25/10=75 seconds.
Using values below 10 does not make sense.
Use -1 to disable this feature which is not recommended because the client will then not be able to detect when the server goes dead.
The default is 25.
This is the client-side analogon to -Ld-ctimeout and specifies the maximum time for the complete authentication to pass (i.e. from initial connection until auth is done).
Use a value of -1 to disable (not recommended).
The default is 10 seconds.
-r-delin, -r-delout, -r-deladd, -f-delin, -f-delout, -f-deladd=SPEC
Specify when the (temporary) render input, render output and additional files needed for rendering, as well as all that for filtering, which were downloaded, should be deleted. These files are downloaded from the LDR server and held on the hard disk by the LDR client in order to execute tasks. Obviously, these files are only needed temporarily and should be removed after some time. These options give you control over that.
Possible values for SPEC are:
frame: delete when the frame was processed
cycle: delete at work cycle end (i.e. disconnect from server)
exit: delete when exiting
never: never delete
Any abbreviation of SPEC is allowed.
Note: All the files are only deleted when they are no longer used (independent of what you specify). If you specify that an additional render file should be deleted on frame basis and the client currently has more than one frame which uses this file, then it is not deleted before all these frames were completely processed. Hence, the additional file will not be deleted and downloaded again for each frame. Note also that the latter would introduce trouble when more than one process is lauched: If RendView deleted and re-downloaded the file, one process may want to read it at the same time and thus fail.
Furthermore, only downloaded files are ever deleted.
The defaults are:
-r-delin, -r-delout: frame
-r-deladd: exit
And the same for the files needed for filter tasks. This means, by default additional files are kept across work cycles which normally does not pose a problem because they are automatically downloaded again when the modification time on the server side is newer than on the client side or file size changed.
NOTE however, that this means that additional files accumulate on the client side. Hence, if you remove an additional file on the server side, it will still be present on the client side and can be accessed.
If enabled, download files again if the time stamp test says so even if the modification time stamp reported by the server did not change in the meantime. Disabling this prevents RendView from loading down more than once a file which was just modified.
Default: disabled, of course! (-no-L-re-download)
-L-always-download-input   (also: -L-adli)
If enabled, always download primary render/filter input file. Normally, RendView does timestamp and size checks on these files, too, so if they are already present, they are not overwritten. The main reason for this option is that when using the frame clock, the same primary render input file may be used for several frames and hence, it makes sense to apply timestamp checks.
Note that when resuming, unfinished render output files are always transferred, irrespective of this option.
Note that on an NFS volume you have to use -L-transfer (instead of this option; see below) to walk around possible problems with file versus system time over NFS.
Default: disabled (-no-L-adli)
The LDR client only downloads files again which are already present when their file size changes or if the modification time on the client is older than on the server. This, however requires synchronisized system times or some means to compensate the difference.
RendView automatically calculates the (worst case) time difference between client and server upon connect and applies this time difference for modification time checks (unless you disable it using -no-L-time-correction).
If really needed, you can switch that off and fall back to -L-timestamp-thresh (see below).
Default: enabled
By default, RendView automatically compensates the difference between client and server time (see -L-time-correction). This parameter can be used to (additionally) hand-tune the timestamp check. Positive values optimize the test ("less files get transterred") because the timestamp thresh gets added to the local file modification time before it is compared to the modification time of the file on the server side.
It's probably better to relay on automatic time correction. You may need this in special cases (maybe with NFS). The default value is 1 msec if -L-time-correction is enabled, otherwise 3001, i.e. 3 seconds.
You can use this to specify which files should be transferred to the LDR client (more precisely: this specifies which files the client will download from the server). The default is all required files and you should be careful when changing that.
You should use -L-transfer=all- when sharing the working directory between the server and this client using e.g. NFS so that no files get transferred. See also the note above.
SPEC is a concatenated list of tags, each with a postfix "+" or "-", e.g. a+rs-rd-fd-
The allowed tags are:
rs, rd, ra: render source, dest and additional files, respectively
fd, fa: filter dest and additional files, respectively
d: all destination files
a: all additional files
all: all files
The SPEC is parsed left-to-right and tags more to the right override those earlier in the spec string.
The default is -L-transfer=all+

<prev [index] next>
Last modified: 2008-02-11 21:06:43 Copyright © 2003 Wolfgang Wieser