If there is enough space in an inode but the file grows the
inode is never written back to the device and thus the new size is
not persisted.
int fd = creat("foo", 660);
write(fd, "foo", 3); // New blocks are allocated and inode written back
write(fd, "\n", 1); // size is adapted but not written back
close(fd);
// Reading the file afterwards will only return "foo".
The code snippet reproduces the bug.
This is fixed by always writing the inode back to the device if
the size is updated.
New blocks for an inode are allocated when data blocks
should be written and not enough blocks are allocated yet
or during allocating new direntries in ext2_allocate_direntry.
When writing the first time to a newly created file (inode.size==0),
new blocks must be allocated and the inode size is erroneously set to
(blocks_count / fs->blocks_per_block_count) * fs->block_size
regardless of the actually written data.
int fd = creat("foo", 0660);
write(fd, "foo", 3);
This code snippet will create a new inode with size 4096 instead
of the correct size 3.
ext2_write_inode_data will correctly set the size to 3.
However, ext2_allocate_block called by ext2_write_inode_block will
set the inode size to 4096.
This is fixed by removing the size update during ext2_allocate_block.
creat.2 is supposed to be equivalent to open.2 with the
flags O_WRONLY|O_CREAT|O_TRUNC.
However, in MentOS the fd returned by creat.2 has no flags whatsoever
and is thus not writable.
Set the flags of the file descriptor before returning it.
I've kept just one cmake project, in the root directory. The
subdirectories just set up the targets.
The asm compiler is serached just one time, from the root
directory cmake file.
Global compilation flags are set in the root cmake file, and
each subdirectory cmake file sets specific flags if necessary
(e.g., programs need the -u_start specified)
I've been cleaning up the way compilation flags are passed to the targets
and there are still some changes that must be made, in the next commit.
I've also done some renaming, all_programs into programs and the same for
tests.
The gdb initialization file now is just one, populated using the find command
and using realpath to get the absolute path to the files. I've tested if the
generated gdb.run file works and it does.
In order to detect the exit status using
WSTATUSCODE ((status & 0xff00) >> 8) the exit code must
be shifted by 8 to the left.
Separate the kernel process exit logic from the actual system call.
Florian Fischer