@@ -49,35 +49,34 @@ The caller:
49
49
When finished writing, the caller can:
50
50
51
51
* Close the file descriptor and rename the lockfile to its final
52
- destination by calling `commit_lock_file`.
52
+ destination by calling `commit_lock_file` or `commit_lock_file_to` .
53
53
54
54
* Close the file descriptor and remove the lockfile by calling
55
55
`rollback_lock_file`.
56
56
57
57
* Close the file descriptor without removing or renaming the lockfile
58
58
by calling `close_lock_file`, and later call `commit_lock_file`,
59
- `rollback_lock_file`, or `reopen_lock_file`.
59
+ `commit_lock_file_to`, ` rollback_lock_file`, or `reopen_lock_file`.
60
60
61
61
Even after the lockfile is committed or rolled back, the `lock_file`
62
62
object must not be freed or altered by the caller. However, it may be
63
63
reused; just pass it to another call of `hold_lock_file_for_update` or
64
64
`hold_lock_file_for_append`.
65
65
66
66
If the program exits before you have called one of `commit_lock_file`,
67
- `rollback_lock_file`, or `close_lock_file`, an `atexit(3)` handler
68
- will close and remove the lockfile, rolling back any uncommitted
69
- changes.
67
+ `commit_lock_file_to`, ` rollback_lock_file`, or `close_lock_file`, an
68
+ `atexit(3)` handler will close and remove the lockfile, rolling back
69
+ any uncommitted changes.
70
70
71
71
If you need to close the file descriptor you obtained from a
72
72
`hold_lock_file_*` function yourself, do so by calling
73
73
`close_lock_file`. You should never call `close(2)` yourself!
74
74
Otherwise the `struct lock_file` structure would still think that the
75
- file descriptor needs to be closed, and a later call to
76
- `commit_lock_file` or `rollback_lock_file` or program exit would
75
+ file descriptor needs to be closed, and a commit or rollback would
77
76
result in duplicate calls to `close(2)`. Worse yet, if you `close(2)`
78
77
and then later open another file descriptor for a completely different
79
- purpose, then a call to `commit_lock_file` or `rollback_lock_file`
80
- might close that unrelated file descriptor.
78
+ purpose, then a commit or rollback might close that unrelated file
79
+ descriptor.
81
80
82
81
83
82
Error handling
@@ -100,9 +99,9 @@ unable_to_lock_die::
100
99
101
100
Emit an appropriate error message and `die()`.
102
101
103
- Similarly, `commit_lock_file` and `close_lock_file` return 0 on
104
- success. On failure they set `errno` appropriately, do their best to
105
- roll back the lockfile, and return -1.
102
+ Similarly, `commit_lock_file`, `commit_lock_file_to`, and
103
+ `close_lock_file` return 0 on success. On failure they set `errno`
104
+ appropriately, do their best to roll back the lockfile, and return -1.
106
105
107
106
108
107
Flags
@@ -156,6 +155,12 @@ commit_lock_file::
156
155
`commit_lock_file` for a `lock_file` object that is not
157
156
currently locked.
158
157
158
+ commit_lock_file_to::
159
+
160
+ Like `commit_lock_file()`, except that it takes an explicit
161
+ `path` argument to which the lockfile should be renamed. The
162
+ `path` must be on the same filesystem as the lock file.
163
+
159
164
rollback_lock_file::
160
165
161
166
Take a pointer to the `struct lock_file` initialized with an
@@ -172,8 +177,9 @@ close_lock_file::
172
177
`hold_lock_file_for_append`, and close the file descriptor.
173
178
Return 0 upon success. On failure to `close(2)`, return a
174
179
negative value and roll back the lock file. Usually
175
- `commit_lock_file` or `rollback_lock_file` should eventually
176
- be called if `close_lock_file` succeeds.
180
+ `commit_lock_file`, `commit_lock_file_to`, or
181
+ `rollback_lock_file` should eventually be called if
182
+ `close_lock_file` succeeds.
177
183
178
184
reopen_lock_file::
179
185
0 commit comments