write_bytes is called with a count of 0 bytes if a directory is being
deleted, because in that case even the . and .. pseudo directories are
getting removed. In this case write_bytes is now a no-op.
Before write_bytes would fail because it would check to see if there
were any blocks available to write in (even though it wasn't going to
write in them anyway).
This behaviour was uncovered because of a recent change where
directories are correctly reduced in size. Which in this case results in
all the blocks being removed from the inode, whereas previously there
would be some stale blocks around to pass the check.
The data structures here were changed from sets to dicts at some point,
with the sets now having different names - this would crash trying to
subtract two dicts.
e2fsck considers all blocks reachable through any of the pointers in
m_raw_inode.i_block as part of this inode regardless of the value in
m_raw_inode.i_size. When it finds more blocks than the amount that
is indicated by i_size or i_blocks it offers to repair the filesystem
by changing those values. That will actually cause further corruption.
So we must zero all pointers to blocks that are now unused.
Previously the directions omitted that you have to specify
`-CMAKE_CXX_COMPILER` when building the Fuzzers. This
would cause all kinds of weird problems at compilation and
link time. You can't specify one or the other, they must
both be pointing at clang in order for things to work as
experted. Fix this by updating the documentation to specify
that the user should specify both the C and CXX compiler explicitly
to be safe, as well as forcing the cmake clang argument handling
to modify the CXX compiler variable instead of the C version.
This links the dynamic linker against libgcc.a instead of having
our own copy of the math functions.
For now we need to specify -fbuilding-libgcc as a hack to work
around a bug with the -nodefaultlibs flag. Once everyone is on
the latest toolchain version this can be removed.
This fixes the -nodefaultlibs flag for gcc which previously
linked against libgcc_s anyway. Even though this is a toolchain
patch we don't need to rebuild the toolchain right away.
There is no need to iterate through all events in a profile when
loading the timeline view, as soon as we see one event we can
move on to the next process.
The current method of emitting performance events requires a bit of
boiler plate at every invocation, as well as having to ignore the
return code which isn't used outside of the perf event syscall. This
change attempts to clean that up by exposing high level API's that
can be used around the code base.
This unix classic attempts to classify and identify information about
given files based on various heuristics. In this case, we're relying on
the Core::MimeData detector for file type and LibGfx::ImageDecoder for
additional metadata if the given file is an image.
It's very simple for now, but adding new detectors should be quite easy.
This attempts to guess the mime-type from a given set of bytes from the
start of a file. It only supports a few well-defined patterns for now,
but it's a start!
