Hello Genodians
I use `run/bash` and added a simple component that logs the content of a ROM module:
```xml <start name="test-update"> <resource name="RAM" quantum="2M"/> <route> <service name="ROM" label="test.config"> <child name="vfs_rom" label="tmp/test.config"/> </service> <any-service> <parent/> <any-child/> </any-service> </route> </start> ```
Then, I execute the following commands on the interactive shell:
```bash
echo "1st-cfg" > /tmp/test.config` # "1st-cfg" is logged mv /tmp/test.config /tmp/test.backup` # nothing is logged echo "2nd-cfg" > /tmp/test.config` # nothing is logged echo "3rd-cfg" > /tmp/test.backup` # "3rd-cfg" is logged
```
Is it the intended behavior that `fs_rom` "follows" the file or should it always provide the ROM content of the file with the specified name instead?
The background of this question is that in fact, `test-update` for example could be a component that consumes the `test.config` and is supposed to react on configuration updates.
Cheers, Roman
Hi Roman,
Then, I execute the following commands on the interactive shell:
> echo "1st-cfg" > /tmp/test.config` # "1st-cfg" is logged > mv /tmp/test.config /tmp/test.backup` # nothing is logged > echo "2nd-cfg" > /tmp/test.config` # nothing is logged > echo "3rd-cfg" > /tmp/test.backup` # "3rd-cfg" is loggedIs it the intended behavior that `fs_rom` "follows" the file or should it always provide the ROM content of the file with the specified name instead?
the behavior is the result of a combination of two things:
- The fs_rom component keeps the file handle for the watched file open during the whole lifetime of the ROM session.
- The <ram> VFS plugin implements the rename operation by modifying the meta data (the naming) but the physical object remains the same. The resolution of the physical object from its name is done only once when the file is opened. The file handle then keeps a reference to the underlying object. Hence, any open file descriptor will "follow" the rename operation.
I think that both points are quite reasonable. Or the other way around, I wonder what would be a sensible alternative?
You can avoid this situation be replacing the 'mv' by 'cp', which will keep the relationship of the original file and its original name intact for open file handles that refer to the file. You can also 'rm' the original file, which will result in an empty ROM, as expected.
Cheers Norman
Hello Norman
On 09.09.20 17:17, Norman Feske wrote:
the behavior is the result of a combination of two things [...]
Thanks for the clarification. The question came up (but is only loosely coupled) with the implementation and testing of file system watch for `lx_fs`.
I think that both points are quite reasonable. Or the other way around, I wonder what would be a sensible alternative?
Intuitively, I would have expected that `fs_rom` always provides the content of the file with the configured file name. If there's no file with that name anymore (because it has been moved or deleted), the ROM would be empty until there is the same (moved back), or another file with the specified file name.
It more or less boils down to the question whether `fs_rom` is "bound" to a file name or a file handle. But I guess the later is the more generally applicable (and agreed upon) definition - which is fine with me ;)
Cheers, Roman
-
Norman Feske -
Roman Iten