Similar to POSIX read, the basic read and write functions of AK::Stream
do not have a lower limit of how much data they read or write (apart
from "none at all").
Rename the functions to "read some [data]" and "write some [data]" (with
"data" being omitted, since everything here is reading and writing data)
to make them sufficiently distinct from the functions that ensure to
use the entire buffer (which should be the go-to function for most
usages).
No functional changes, just a lot of new FIXMEs.
This will make it easier to support both string types at the same time
while we convert code, and tracking down remaining uses.
One big exception is Value::to_string() in LibJS, where the name is
dictated by the ToString AO.
We have a new, improved string type coming up in AK (OOM aware, no null
state), and while it's going to use UTF-8, the name UTF8String is a
mouthful - so let's free up the String name by renaming the existing
class.
Making the old one have an annoying name will hopefully also help with
quick adoption :^)
This prevents us from needing a sv suffix, and potentially reduces the
need to run generic code for a single character (as contains,
starts_with, ends_with etc. for a char will be just a length and
equality check).
No functional changes.
Each of these strings would previously rely on StringView's char const*
constructor overload, which would call __builtin_strlen on the string.
Since we now have operator ""sv, we can replace these with much simpler
versions. This opens the door to being able to remove
StringView(char const*).
No functional changes.
A mistake I've repeatedly made is along these lines:
```c++
auto nread = TRY(source_file->read(buffer));
TRY(destination_file->write(buffer));
```
It's a little clunky to have to create a Bytes or StringView from the
buffer's data pointer and the nread, and easy to forget and just use
the buffer. So, this patch changes the read() function to return a
Bytes of the data that were just read.
The other read_foo() methods will be modified in the same way in
subsequent commits.
Fixes#13687
For file copying, when there is a file with the same name in the
destination directory, the file will be automatically renamed to
"file-2.txt", for example. This change expands that special-case
handling to file moving.
When there is a file with the same name in the destination directory,
FileManager overwrites that file without any warning. With this change,
such a file will be automatically renamed to "emoji-2.txt", for example.
Also, currently there is a check in FileManager that makes copy and
paste of a file in the same directory no-op. This change removes that
check, because it is no longer a problem.
Deleting a symlink via "FileOperation Delete" should not recursively
delete whatever the symlink is pointing to. Same basic idea applies to
the Copy and Move operations.
The upcoming 'Delete' operation has no destination, so this was the
best solution we could come up with for now. Perhaps ArgsParser
could support sub-commands, so we would define 'Copy', 'Move' and
'Delete' each as sub-commands with their own argument definitions.
That would make things like git's variety of commands possible.
You can now list multiple files or directories and they will all be
copied to the destination. :^)
Note that this means you can pass the same file or directory multiple
times. It runs fine, just means that it does unnecessary work. But
figuring out if a file is already queued is probably more hassle than
it's worth, if it's even possible at all due to symlinks.
The LexicalPath instance methods dirname(), basename(), title() and
extension() will be changed to return StringView const& in a further
commit. Due to this, users creating temporary LexicalPath objects just
to call one of those getters will recieve a StringView const& pointing
to a possible freed buffer.
To avoid this, static methods for those APIs have been added, which will
return a String by value to avoid those problems. All cases where
temporary LexicalPath objects have been used as described above haven
been changed to use the static APIs.
SPDX License Identifiers are a more compact / standardized
way of representing file license information.
See: https://spdx.dev/resources/use/#identifiers
This was done with the `ambr` search and replace tool.
ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
What I meant for the GUI progress bars to show:
- Bytes copied of the current file
- Files copied of the total set
What it actually showed:
- Bytes copied of the total bytes
- Files copied of the total set
This patch fixes it by showing byte progress of the current file
instead of byte progress of total bytes.
This is a helper program for FileManager that performs a file operation
in a separate process and reports progress on standard out.
This initial implementation only supports the "Copy" operation and does
not do any detailed error handling.
