| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
That's a total no-no, hence rework this to use malloc()-based memory instead of
alloca()-based memory.
Also see CODING_STYLE about this.
|
|
|
|
|
|
|
|
| |
We previously would fail with EOPNOTSUPP when encountering an AF_UNIX socket in
the directory tree to copy. Fix that, and copy them too (even if they are dead
in the result).
Fixes: #2914
|
|
|
|
|
|
|
|
| |
copy_bytes() and the comparisons in test_copy_bytes_regular_file() expect an
uint64_t, not a size_t. On 32 bit architectures the latter is 32 bit, leading
to truncation errors.
Fixes regression from commit 7a827fcb.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
I started looking into adding copy_file_range support, and discovered
that we can improve the way we call sendfile:
- sendfile(2) man page is missing an important bit: the number of bytes to
copy cannot be too big (SSIZE_MAX actually), and the description of EINVAL
return code does not mention this either,
- our implementation works but calls sendfile over and over with a small
size, which seems suboptimal.
First add a test which (under strace) can be used to see current behaviour.
|
| |
|
| |
|
|
|
|
|
| |
There are more than enough to deserve their own .c file, hence move them
over.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
string-util.[ch]
There are more than enough calls doing string manipulations to deserve
its own files, hence do something about it.
This patch also sorts the #include blocks of all files that needed to be
updated, according to the sorting suggestions from CODING_STYLE. Since
pretty much every file needs our string manipulation functions this
effectively means that most files have sorted #include blocks now.
Also touches a few unrelated include files.
|
|
|
|
|
|
|
|
|
|
|
| |
off_t is a really weird type as it is usually 64bit these days (at least
in sane programs), but could theoretically be 32bit. We don't support
off_t as 32bit builds though, but still constantly deal with safely
converting from off_t to other types and back for no point.
Hence, never use the type anymore. Always use uint64_t instead. This has
various benefits, including that we can expose these values directly as
D-Bus properties, and also that the values parse the same in all cases.
|
|
|
|
|
|
|
| |
Merge write_string_file(), write_string_file_no_create() and
write_string_file_atomic() into write_string_file() and provide a flags mask
that allows combinations of atomic writing, newline appending and automatic
file creation. Change all users accordingly.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
- Move to its own file rm-rf.c
- Change parameters into a single flags parameter
- Remove "honour sticky" logic, it's unused these days
|
|
|
|
|
|
| |
After all it is now much more like strjoin() than strappend(). At the
same time, add support for NULL sentinels, even if they are normally not
necessary.
|
| |
|
| |
|
|
|
|
| |
sendfile_full() by it
|
|
|