Now it is possible to run applications, do Git checkouts, etc.
on a ramfs (and those seem to work just fine -- a git checkout
followed by a git fsck both succeeded.)
This adds one (private) VFS function, and checks in all usages of
the vnode->cache as a VMVnodeCache that it really is one. (Generic
usages, for the moment just the ReleaseRef() calls in vnode
destruction, are intentionally not touched.)
This will be used by ramfs to set the cache from its own,
so that map_file() calls on a ramfs can work.
This only works because DataCollector stores its data in blocks
which are mapped into the kernel's address space. After the
next series of commits, it won't, so we can't depend on that.
This required some changes to the indexes to keep a copy of the
keys.
Now that Attributes don't use a table, we can replace the generic
system with a specific DirectoryEntryTable, upgrading to BOpenHashTable
in the process.
This is what packagefs does; so if it's performant enough for packagefs,
it's performant enough for us. Greatly simplifies this code (and will
allow for further simplification of the NodeChildHash.)
The "exec" tool can only handle one command with environs set at
the beginning of the line, so now we set the ADD_BUILD_COMPAT...
in this format. This also seems to be a general performance
improvement to builds using real shells, too.
Change-Id: If4b3117651b5475039d5e8116cd3de398582290a
Refactored out of execvpe. Originally I did this for my attempted
change to posix_spawn, but that change turned out to be wrong and
actually not that beneficial. This bit seems potentially useful,
though, so here it is.
- It appears that, in this case, port->open_fd is NULL.
Maybe, this would require some investigation too.
But in this case, i think it is better to remove port
from the device list anyway because remove_port will freed
the port at the end of the loop.
And adding 0xdeadbeef in the device list is not a good idea.
Change-Id: Id6b55f5e19ebbbbb48f0fa0b7d9ac65b996dbaf2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1746
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Having valid superblocks from multiple filesystems on the same disk is
confusing, let's try to avoid that.
Change-Id: I1a58843d45ea52193a77faaf8dcc3ca6a049406e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1802
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
If multipole filesystems think they can handle a volume, it makes sense
to assume the native one is to be used.
Makes my partitions with a BFS superblock and a leftover ext2 superblock
on them mountable again without manually specifying the filesystem type.
Fixes#15045.
Change-Id: Icb694472aa3de0a79e5f7d3c54976038e1e2590a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1801
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
I have two partitions which used to be ext2, but have long since been
reinitialized as BFS. However, the ext2 superblock is still here, and
the ext2 filesystem will detect it. It crashes later on trying to access
an Inode at block -1, so just add a check for that to avoid the crash.
Change-Id: Ie2ed6a969ea3ffd343dedfe45a15dfc37af05804
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1800
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Use 2D icons for mount modes: encrypted, file, readonly, shared
('boot' already uses he 2D Overlay_leaf)
* Use more vibrant colors for used space indicators.
(red = readonly, green = BFS, blue = non-BFS, grey/orange = encrypted)
* Don't have boot/bfs partitions override readonly status (red) with
green. Keep it simple: if anything mounts read-only, show in red.
Change-Id: I4a7c53e1c1d3c6f4be35cbd680b2a7b5e1f9bea3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1755
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Fix hardcoded black color in SeparatorView that caused invisible or
hard to read labels if you had a dark panel color. E.g MediaPrefs
* DrawBorder in HaikuControl didn't care about dark mode. Added check
for light/dark and changed the Tinting accordingly. We should probably
do the same for FancyBorder style as well.
Change-Id: I065211e56b0db5acd05ea287d6cacf75786f306f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1751
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
