redoxfs issueshttps://gitlab.redox-os.org/redox-os/redoxfs/-/issues2023-10-18T00:07:21Zhttps://gitlab.redox-os.org/redox-os/redoxfs/-/issues/44Disk encryption uses AES in ECB mode2023-10-18T00:07:21ZJavaDisk encryption uses AES in ECB modeThe encryption feature of the FS encrypts all AES-blocks with the same key, therefor the encryption is ineffective and barely does anything.
Good example of what the issue with ECB is:
![image](/uploads/04818ee0cef5de84c8fb1c3e9c4e7bff...The encryption feature of the FS encrypts all AES-blocks with the same key, therefor the encryption is ineffective and barely does anything.
Good example of what the issue with ECB is:
![image](/uploads/04818ee0cef5de84c8fb1c3e9c4e7bff/image.png)
More information about issues with ECB:
https://crypto.stackexchange.com/questions/20941/why-shouldnt-i-use-ecb-encryptionhttps://gitlab.redox-os.org/redox-os/redoxfs/-/issues/42Tooling2023-07-18T18:12:01ZRibbonToolingThis issue will cover the necessary tools for RedoxFS.
- [ ] Volume management
- [ ] Partition management
- [ ] Encryption management
- [ ] Compression management
- [ ] Enable/disable volumes
- [ ] Mount/unmount devicesThis issue will cover the necessary tools for RedoxFS.
- [ ] Volume management
- [ ] Partition management
- [ ] Encryption management
- [ ] Compression management
- [ ] Enable/disable volumes
- [ ] Mount/unmount deviceshttps://gitlab.redox-os.org/redox-os/redoxfs/-/issues/41with_redoxfs is failing to remove image.bin in mmap and simple tests2023-03-17T10:08:30ZWill Angenentwith_redoxfs is failing to remove image.bin in mmap and simple testsThis job is failing on [master](https://gitlab.redox-os.org/freewilll/redoxfs/-/jobs/38053).
```
[src/tests.rs:40] format!(":{}", mount_path) = ":image"
[src/tests.rs:40] fs::remove_file(dbg!(format! (":{}", mount_path))) = Ok(
(),
...This job is failing on [master](https://gitlab.redox-os.org/freewilll/redoxfs/-/jobs/38053).
```
[src/tests.rs:40] format!(":{}", mount_path) = ":image"
[src/tests.rs:40] fs::remove_file(dbg!(format! (":{}", mount_path))) = Ok(
(),
)
[src/tests.rs:69] disk_path = "image.bin"
[src/tests.rs:69] fs::remove_file(dbg!(disk_path)) = Err(
Os {
code: 2,
kind: NotFound,
message: "No such file or directory",
},
)
```
The failing [line](https://gitlab.redox-os.org/redox-os/redoxfs/-/blob/master/src/tests.rs#L69).
Looks like the cleanup code is failing to remove the temporary image `image.bin` created in `with_redoxfs`. It can be reproduced with:
```
#[test]
fn simple1() {
with_redoxfs(|path| {
})
}
```
Actually, in the [CI job](https://gitlab.redox-os.org/redox-os/redoxfs/-/jobs/37782) for the last release, 0.5.4 had this failing test too. Furthermore, this test has been failing for the last 3 years. The last passing test was [this one](https://gitlab.redox-os.org/redox-os/redoxfs/-/pipelines/7157).https://gitlab.redox-os.org/redox-os/redoxfs/-/issues/38File Locking2018-06-16T08:06:32ZSamwiseFilmoremggmugginsmc@gmail.comFile LockingImplement file locking. From what @jackpot51 said, locking is to be mandatory.Implement file locking. From what @jackpot51 said, locking is to be mandatory.https://gitlab.redox-os.org/redox-os/redoxfs/-/issues/12panic when copying file with non-utf8 filename2023-03-07T22:40:04ZJeremy Sollerpanic when copying file with non-utf8 filename*Created by: bungcip*
**how to reproduce**
- the simple way to create non-utf8 is by using python
```
python
>>> open('hello\xff.txt','w')
<open file 'hello\xff.txt', mode 'w' at 0x7f98ae0a5540>
```
- then copy the file to redoxf...*Created by: bungcip*
**how to reproduce**
- the simple way to create non-utf8 is by using python
```
python
>>> open('hello\xff.txt','w')
<open file 'hello\xff.txt', mode 'w' at 0x7f98ae0a5540>
```
- then copy the file to redoxfs mounted folder
```
cp helloâ–’.txt ~/repo/redoxfs/image
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /checkout/src/libcore/option.rs:329
note: Run with `RUST_BACKTRACE=1` for a backtrace.
```
**expected output**
well, at least don't panic.
- if we want redoxfs behave like other linux filesystem which just store filename as blob then the operation must be sucess.
- if we want redoxfs to enforce utf8 filename on disk format then the operation must fail with showing useful error message.https://gitlab.redox-os.org/redox-os/redoxfs/-/issues/10Add `cargo test` tests2018-06-16T08:06:32ZJeremy SollerAdd `cargo test` testsAdd integration tests to catch things like https://github.com/redox-os/redox/issues/873Add integration tests to catch things like https://github.com/redox-os/redox/issues/873https://gitlab.redox-os.org/redox-os/redoxfs/-/issues/5Minor memory leak due to channel not being closed2018-06-16T08:06:32ZJeremy SollerMinor memory leak due to channel not being closed*Created by: genodeftest*
Steps to reproduce:
1. build redoxfs with `cargo build`
2. run `$ valgrind --leak-check=full --vgdb=full schemes/redoxfs/target/debug/redoxfs-fuse build/userspace/filesystem.bin build/userspace/filesystem`
...*Created by: genodeftest*
Steps to reproduce:
1. build redoxfs with `cargo build`
2. run `$ valgrind --leak-check=full --vgdb=full schemes/redoxfs/target/debug/redoxfs-fuse build/userspace/filesystem.bin build/userspace/filesystem`
What happens:
```
==15039== Memcheck, a memory error detector
==15039== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==15039== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==15039== Command: schemes/redoxfs/target/debug/redoxfs-fuse build/userspace/filesystem.bin build/userspace/filesystem
==15039==
redoxfs: opened filesystem build/userspace/filesystem.bin
==15039==
==15039== HEAP SUMMARY:
==15039== in use at exit: 26 bytes in 2 blocks
==15039== total heap usage: 16 allocs, 14 frees, 35,084 bytes allocated
==15039==
==15039== 26 (16 direct, 10 indirect) bytes in 1 blocks are definitely lost in loss record 2 of 2
==15039== at 0x4C2DADE: malloc (vg_replace_malloc.c:298)
==15039== by 0x4C2FC91: realloc (vg_replace_malloc.c:785)
==15039== by 0x4E5283F: fuse_opt_add_arg (fuse_opt.c:61)
==15039== by 0x4E52F67: add_arg (fuse_opt.c:114)
==15039== by 0x4E52F67: opt_parse (fuse_opt.c:374)
==15039== by 0x4E52F67: fuse_opt_parse (fuse_opt.c:414)
==15039== by 0x4E58D38: fuse_kern_mount (mount.c:588)
==15039== by 0x143C2C: fuse::channel::Channel::new::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::hd991d380a692231b (channel.rs:85)
==15039== by 0x13C888: fuse::channel::with_fuse_args::h86d660b80b2a8622 (channel.rs:66)
==15039== by 0x143623: fuse::channel::Channel::new::_$u7b$$u7b$closure$u7d$$u7d$::h953967d5ac53bd71 (channel.rs:84)
==15039== by 0x134C41: _$LT$core..result..Result$LT$T$C$$u20$E$GT$$GT$::and_then::hb6320c7449f2ba88 (result.rs:601)
==15039== by 0x13CC0B: fuse::channel::Channel::new::h104f7eb0c1c40ef1 (channel.rs:83)
==15039== by 0x114CED: _$LT$fuse..session..Session$LT$FS$GT$$GT$::new::h866d4ed59279cc77 (session.rs:50)
==15039== by 0x11A4BC: fuse::mount::h11c4652a3452f21d (lib.rs:377)
==15039==
==15039== LEAK SUMMARY:
==15039== definitely lost: 16 bytes in 1 blocks
==15039== indirectly lost: 10 bytes in 1 blocks
==15039== possibly lost: 0 bytes in 0 blocks
==15039== still reachable: 0 bytes in 0 blocks
==15039== suppressed: 0 bytes in 0 blocks
==15039==
==15039== For counts of detected and suppressed errors, rerun with: -v
==15039== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
```
Expected behavior: No memory lost on exit. The traceback looks like a channel is opened but not closed.