_index` for the
first mapping, but since `first_mapping_index` is only used here,
another approach is to just check manually for the
`mapping->first_mapping_index != -1` since we know that this is the
value for the only entry where `offset == 0` (i.e. first mapping).
Signed-off-by: Amjad Alsharafi
dn't open anything) we
will get the offset into the file with
`s->cluster_size*(cluster_num-s->current_mapping->begin)`, which will
give us `0x2000 * (504-500)`, which is out of bound for this mapping and
will produce some issues.
Signed-off-by: Amjad Alsharafi
---
block/vvfat.c | 10
Added several tests to verify the implementation of the vvfat driver.
We needed a way to interact with it, so created a basic `fat16.py` driver
that handled writing correct sectors for us.
Added `vvfat` to the non-generic formats, as its not a normal image format.
Signed-off-by: Amjad Alsharafi
!< offset=0x2000`,
thus not fetching the next cluster.
Signed-off-by: Amjad Alsharafi
Reviewed-by: Kevin Wolf
Tested-by: Kevin Wolf
---
block/vvfat.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/block/vvfat.c b/block/vvfat.c
index 9d050ba3ae..19da009a5b 100
in vvfat
Amjad Alsharafi (5):
vvfat: Fix bug in writing to middle of file
vvfat: Fix usage of `info.file.offset`
vvfat: Fix wrong checks for cluster mappings invariant
vvfat: Fix reading files with non-continuous clusters
iotests: Add `vvfat` tests
block/vvfat.c | 34
The field is marked as "the offset in the file (in clusters)", but it
was being used like this
`cluster_size*(nums)+mapping->info.file.offset`, which is incorrect.
Signed-off-by: Amjad Alsharafi
Reviewed-by: Kevin Wolf
---
block/vvfat.c | 11 +++
1 file changed, 7 ins
On Jul 19 2024, at 8:20 am, Amjad Alsharafi wrote:
> On Thu, Jul 18, 2024 at 05:20:36PM +0200, Kevin Wolf wrote:
>> Am 12.06.2024 um 14:43 hat Amjad Alsharafi geschrieben:
>> > When reading with `read_cluster` we get the `mapping` with
>> > `find_mapping_fo
On Thu, Jul 18, 2024 at 05:20:36PM +0200, Kevin Wolf wrote:
> Am 12.06.2024 um 14:43 hat Amjad Alsharafi geschrieben:
> > When reading with `read_cluster` we get the `mapping` with
> > `find_mapping_for_cluster` and then we call `open_file` for this
> > mapping.
> >
Can I get review for this patch?
Thanks,
Best regards,
Amjad
On Wed, Jun 12, 2024 at 08:43:21PM +0800, Amjad Alsharafi wrote:
> These patches fix some bugs found when modifying files in vvfat.
> First, there was a bug when writing to the cluster 2 or above of a file, it
> will copy th
On Wed, Jun 12, 2024 at 08:43:26PM +0800, Amjad Alsharafi wrote:
> Added several tests to verify the implementation of the vvfat driver.
>
> We needed a way to interact with it, so created a basic `fat16.py` driver
> that handled writing correct sectors for us.
>
> Added
dn't open anything) we
will get the offset into the file with
`s->cluster_size*(cluster_num-s->current_mapping->begin)`, which will
give us `0x2000 * (504-500)`, which is out of bound for this mapping and
will produce some issues.
Signed-off-by: Amjad Alsharafi
---
Added several tests to verify the implementation of the vvfat driver.
We needed a way to interact with it, so created a basic `fat16.py` driver
that handled writing correct sectors for us.
Added `vvfat` to the non-generic formats, as its not a normal image format.
Signed-off-by: Amjad Alsharafi
_index` for the
first mapping, but since `first_mapping_index` is only used here,
another approach is to just check manually for the
`mapping->first_mapping_index != -1` since we know that this is the
value for the only entry where `offset == 0` (i.e. first mapping).
Signed-off-by: Amjad
The field is marked as "the offset in the file (in clusters)", but it
was being used like this
`cluster_size*(nums)+mapping->info.file.offset`, which is incorrect.
Signed-off-by: Amjad Alsharafi
---
block/vvfat.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-
:
https://patchew.org/QEMU/20240327201231.31046-1-amjadsharaf...@gmail.com/
Fix the issue of writing to the middle of the file in vvfat
Amjad Alsharafi (5):
vvfat: Fix bug in writing to middle of file
vvfat: Fix usage of `info.file.offset`
vvfat: Fix wrong checks for cluster mappings
!< offset=0x2000`,
thus not fetching the next cluster.
Signed-off-by: Amjad Alsharafi
Reviewed-by: Kevin Wolf
Tested-by: Kevin Wolf
---
block/vvfat.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/block/vvfat.c b/block/vvfat.c
index 9d050ba3ae..19da009a5b 100
On Tue, Jun 11, 2024 at 04:30:53PM +0200, Kevin Wolf wrote:
> Am 11.06.2024 um 14:31 hat Amjad Alsharafi geschrieben:
> > On Mon, Jun 10, 2024 at 06:49:43PM +0200, Kevin Wolf wrote:
> > > Am 05.06.2024 um 02:58 hat Amjad Alsharafi geschrieben:
> > > > The field is mar
On Mon, Jun 10, 2024 at 06:49:43PM +0200, Kevin Wolf wrote:
> Am 05.06.2024 um 02:58 hat Amjad Alsharafi geschrieben:
> > The field is marked as "the offset in the file (in clusters)", but it
> > was being used like this
> > `cluster_size*(nums)+mapping->inf
On Mon, Jun 10, 2024 at 02:01:24PM +0200, Kevin Wolf wrote:
> Am 05.06.2024 um 02:58 hat Amjad Alsharafi geschrieben:
> > Added several tests to verify the implementation of the vvfat driver.
> >
> > We needed a way to interact with it, so created a basic `fat16.py` dri
sts/fat16.py
new file mode 100644
index 00..baf801b4d5
--- /dev/null
+++ b/tests/qemu-iotests/fat16.py
@@ -0,0 +1,635 @@
+# A simple FAT16 driver that is used to test the `vvfat` driver in QEMU.
+#
+# Copyright (C) 2024 Amjad Alsharafi
+#
+# This program is free software; you can redistrib
new clusters for files, and
its inevitable that we reach this condition when doing that if the
clusters are not after one another, so there is no reason to `abort`
here, execution continues and the new clusters are written to disk
correctly.
Signed-off-by: Amjad Alsharafi
---
block/vvfat.c | 12 +++
dn't open anything) we
will get the offset into the file with
`s->cluster_size*(cluster_num-s->current_mapping->begin)`, which will
give us `0x2000 * (504-500)`, which is out of bound for this mapping and
will produce some issues.
Signed-off-by: Amjad Alsharafi
---
!< offset=0x2000`,
thus not fetching the next cluster.
Signed-off-by: Amjad Alsharafi
Reviewed-by: Kevin Wolf
Tested-by: Kevin Wolf
---
block/vvfat.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/block/vvfat.c b/block/vvfat.c
index 9d050ba3ae..19da009a5b 100
/
Fix the issue of writing to the middle of the file in vvfat
Amjad Alsharafi (4):
vvfat: Fix bug in writing to middle of file
vvfat: Fix usage of `info.file.offset`
vvfat: Fix reading files with non-continuous clusters
iotests: Add `vvfat` tests
block/vvfat.c | 38
On Fri, May 31, 2024 at 07:22:49PM +0200, Kevin Wolf wrote:
> Am 26.05.2024 um 11:56 hat Amjad Alsharafi geschrieben:
> > These patches fix some bugs found when modifying files in vvfat.
> > First, there was a bug when writing to the cluster 2 or above of a file, it
> >
!< offset=0x2000`,
thus not fetching the next cluster.
Signed-off-by: Amjad Alsharafi
---
block/vvfat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/vvfat.c b/block/vvfat.c
index 9d050ba3ae..ab342f0743 100644
--- a/block/vvfat.c
+++ b/block/vvfat.c
@@ -2525,7 +252
We test the ability to create new files in the filesystem, this is done by
adding an entry in the desired directory list.
The file will also be created in the host filesystem with matching filename.
Signed-off-by: Amjad Alsharafi
---
tests/qemu-iotests/fat16.py| 124
Amjad Alsharafi (6):
vvfat: Fix bug in writing to middle of file
vvfat: Fix usage of `info.file.offset`
vvfat: Fix reading files with non-continuous clusters
iotests: Add `vvfat` tests
iotests: Filter out `vvfat` fmt from failing tests
iotests: Add `create_file` test for `vvfat` driver
new clusters for files, and
its inevitable that we reach this condition when doing that if the
clusters are not after one another, so there is no reason to `abort`
here, execution continues and the new clusters are written to disk
correctly.
Signed-off-by: Amjad Alsharafi
---
block/vvfat.c | 9
`vvfat` is a special format and not all tests (even generic) can run without
crashing.
So, added `unsupported_fmt: vvfat` to all failling tests.
Also added `vvfat` format into `meson.build`, vvfaat tests can be run on the
`block-thorough` suite.
Signed-off-by: Amjad Alsharafi
---
.gitlab
Added several tests to verify the implementation of the vvfat driver.
We needed a way to interact with it, so created a basic `fat16.py` driver that
handled writing correct sectors for us.
Signed-off-by: Amjad Alsharafi
---
tests/qemu-iotests/check | 2 +-
tests/qemu-iotests/fat16
dn't open anything) we
will get the offset into the file with
`s->cluster_size*(cluster_num-s->current_mapping->begin)`, which will
give us `0x2000 * (504-500)`, which is out of bound for this mapping and
will produce some issues.
Signed-off-by: Amjad Alsharafi
---
, Amjad Alsharafi wrote:
> v2:
> Added iotests for `vvfat` driver along with a simple `fat16` module to run
> the tests.
>
> v1:
> https://patchew.org/QEMU/20240327201231.31046-1-amjadsharaf...@gmail.com/
> Fix the issue of writing to the middle of the file in vvfat
&
Added several tests to verify the implementation of the vvfat driver.
We needed a way to interact with it, so created a basic `fat16.py` driver that
handled writing correct sectors for us.
Signed-off-by: Amjad Alsharafi
---
tests/qemu-iotests/check | 2 +-
tests/qemu-iotests/fat16
`vvfat` is a special format and not all tests (even generic) can run without
crashing.
So, added `unsupported_fmt: vvfat` to all failling tests.
Also added `vvfat` format into `meson.build`, vvfaat tests can be run on the
`block-thorough` suite.
Signed-off-by: Amjad Alsharafi
---
.gitlab
new clusters for files, and
its inevitable that we reach this condition when doing that if the
clusters are not after one another, so there is no reason to `abort`
here, execution continues and the new clusters are written to disk
correctly.
Signed-off-by: Amjad Alsharafi
---
block/vvfat.c | 9
dn't open anything) we
will get the offset into the file with
`s->cluster_size*(cluster_num-s->current_mapping->begin)`, which will
give us `0x2000 * (504-500)`, which is out of bound for this mapping and
will produce some issues.
Signed-off-by: Amjad Alsharafi
---
v2:
Added iotests for `vvfat` driver along with a simple `fat16` module to run
the tests.
v1:
https://patchew.org/QEMU/20240327201231.31046-1-amjadsharaf...@gmail.com/
Fix the issue of writing to the middle of the file in vvfat
Amjad Alsharafi (5):
vvfat: Fix bug in writing to middle
!< offset=0x2000`,
thus not fetching the next cluster.
Signed-off-by: Amjad Alsharafi
---
block/vvfat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/vvfat.c b/block/vvfat.c
index 9d050ba3ae..ab342f0743 100644
--- a/block/vvfat.c
+++ b/block/vvfat.c
@@ -2525,7 +252
Ping again
On Apr 13 2024, at 5:51 pm, Amjad Alsharafi wrote:
> Ping to the vvfat maintainers.
>
Ping to the vvfat maintainers.
I noticed the issue in the commit message 'ffvat' should be 'vvfat',
I'll fix it in the next version.
On Thu, Mar 28, 2024 at 04:11:27AM +0800, Amjad Alsharafi wrote:
> When reading with `read_cluster` we get the `mapping` with
> `find_mapping_for_cluster` and then we call `ope
!< offset=0x2000`,
thus not fetching the next cluster.
Signed-off-by: Amjad Alsharafi
---
block/vvfat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/vvfat.c b/block/vvfat.c
index 9d050ba3ae..ab342f0743 100644
--- a/block/vvfat.c
+++ b/block/vvfat.c
@@ -2525,7 +252
dn't open anything) we
will get the offset into the file with
`s->cluster_size*(cluster_num-s->current_mapping->begin)`, which will
give us `0x2000 * (504-500)`, which is out of bound for this mapping and
will produce some issues.
Signed-off-by: Amjad Alsharafi
---
These patches fix some bugs found when modifying files in vvfat.
First, there was a bug when writing to the second+ cluster of a file, it
will copy the cluster before it instead.
Another issue was modifying the clusters of a file and adding new
clusters, this showed 2 issues:
- If the new
new clusters for files, and
its inevitable that we reach this condition when doing that if the
clusters are not after one another, so there is no reason to `abort`
here, execution continues and the new clusters are written to disk
correctly.
Signed-off-by: Amjad Alsharafi
---
block/vvfat.c | 9
46 matches
Mail list logo
