Re: [feature request] extract a single file from EROFS filesystem

Re: [feature request] extract a single file from EROFS filesystem

[Mingye Wang]

Hi all,

>Gao Xiang Thu, 09 Jan 2025 01:36:16 -0800
>On 2025/1/9 02:14, Daniel Erez wrote:
>>Would it be applicable to introduce an option for extracting a specific file
>>from the image?
>>I.e. something similar to the '-extract-file' option available in unsquashfs tool [2].
>I will add this later.

I am seeing a need for a similar feature in making dracut's lsinitrd
work... a little better. I should add two cents of my own.

* In "unsquashfs" there's not only '-extract-file' for passing in a
list of files, but also a possibility for a list of paths to be
specified directly as arguments. This would appear outlandish on an
fsck utility.
* When extracting single files it might be desirable to *not* verify
and pretend-extract the other files.

Because of these two reasons, I think it might be best to make an
"unerofs" for extraction purposes instead of adding more things to the
"fsck" tool. An initial version can just be a separate "main" fuction
in fsck.c that gets used when an argv[0] equal to "unerofs" or ending
with "/unerofs" is found.

Sincerely,
Mingye Wang (Artoria2e5)

Re: [feature request] extract a single file from EROFS filesystem

[Gao Xiang]

Hi Mingye,

On Mon, Jul 14, 2025 at 12:55:06AM +0800, Mingye Wang wrote:
> Hi all,
> 
> >Gao Xiang Thu, 09 Jan 2025 01:36:16 -0800
> >On 2025/1/9 02:14, Daniel Erez wrote:
> >>Would it be applicable to introduce an option for extracting a specific file
> >>from the image?
> >>I.e. something similar to the '-extract-file' option available in unsquashfs tool [2].
> >I will add this later.
> 
> I am seeing a need for a similar feature in making dracut's lsinitrd
> work... a little better. I should add two cents of my own.

dump.erofs already supports `--cat` command to dump a single file.

> 
> * In "unsquashfs" there's not only '-extract-file' for passing in a
> list of files, but also a possibility for a list of paths to be
> specified directly as arguments. This would appear outlandish on an
> fsck utility.

Can those be replaced as dump.erofs --cat?

> * When extracting single files it might be desirable to *not* verify
> and pretend-extract the other files.

`fsck.erofs` can be used to dump a subtree in the future (exclude file
pattern can be applied), fsck/dump/mkfs tools are more common for
generic filesystems.

Mimick Squashfs-specific is not EROFS will do since I do see `un`-prefix
is common and lack of (even defacto) standardization.

Thanks,
Gao Xiang

Re: [feature request] extract a single file from EROFS filesystem

[Gao Xiang]

On Mon, Jul 14, 2025 at 08:02:13AM +0800, Gao Xiang wrote:
> Hi Mingye,
> 
> On Mon, Jul 14, 2025 at 12:55:06AM +0800, Mingye Wang wrote:
> > Hi all,
> > 
> > >Gao Xiang Thu, 09 Jan 2025 01:36:16 -0800
> > >On 2025/1/9 02:14, Daniel Erez wrote:
> > >>Would it be applicable to introduce an option for extracting a specific file
> > >>from the image?
> > >>I.e. something similar to the '-extract-file' option available in unsquashfs tool [2].
> > >I will add this later.
> > 
> > I am seeing a need for a similar feature in making dracut's lsinitrd
> > work... a little better. I should add two cents of my own.
> 
> dump.erofs already supports `--cat` command to dump a single file.
> 
> > 
> > * In "unsquashfs" there's not only '-extract-file' for passing in a
> > list of files, but also a possibility for a list of paths to be
> > specified directly as arguments. This would appear outlandish on an
> > fsck utility.
> 
> Can those be replaced as dump.erofs --cat?
> 
> > * When extracting single files it might be desirable to *not* verify
> > and pretend-extract the other files.
> 
> `fsck.erofs` can be used to dump a subtree in the future (exclude file
> pattern can be applied), fsck/dump/mkfs tools are more common for
> generic filesystems.
> 
> Mimick Squashfs-specific is not EROFS will do since I do see `un`-prefix
> is common and lack of (even defacto) standardization.

In other words, if you care more about a subtree or a whole filesystem
dump, all (sub-)tree metadata/data should be checked first, and that is
what `fsck.erofs` does and the dumped files are only side products for
data verification (because fsck needs to check compressed data is valid
too.)

If you only care about some individual inodes, that is what `dump.erofs`
works, including `--cat` shows inode content, `--ls` shows directory
content, `-e` shows extent map, etc.

Thanks,
Gao Xiang

> 
> Thanks,
> Gao Xiang
> 

[feature request] extract a single file from EROFS filesystem

[Daniel Erez]

[-- Attachment #1: Type: text/plain, Size: 528 bytes --]

Hi,

According to fsck.erofs manual [1], the tool supports extracting the whole
file system.
Would it be applicable to introduce an option for extracting a specific
file from the image?
I.e. something similar to the '-extract-file' option available in
unsquashfs tool [2].
Or, is there any other alternative for extracting a file from an EROFS
image?

[1] https://man.archlinux.org/man/extra/erofs-utils/fsck.erofs.1.en#extract
[2]
https://manpages.debian.org/testing/squashfs-tools/unsquashfs.1.en.html#extract

Thanks!
Daniel

[-- Attachment #2: Type: text/html, Size: 798 bytes --]

Re: [feature request] extract a single file from EROFS filesystem

[Gao Xiang]

Hi,

On 2025/1/9 02:14, Daniel Erez wrote:
> Hi,
> 
> According to fsck.erofs manual [1], the tool supports extracting the whole file system.
> Would it be applicable to introduce an option for extracting a specific file from the image?
> I.e. something similar to the '-extract-file' option available in unsquashfs tool [2].
> Or, is there any other alternative for extracting a file from an EROFS image?
> 
> [1] https://man.archlinux.org/man/extra/erofs-utils/fsck.erofs.1.en#extract <https://man.archlinux.org/man/extra/erofs-utils/fsck.erofs.1.en#extract>
> [2] https://manpages.debian.org/testing/squashfs-tools/unsquashfs.1.en.html#extract <https://manpages.debian.org/testing/squashfs-tools/unsquashfs.1.en.html#extract>

I will add this later.

Thanks,
Gao Xiang

> 
> Thanks!
> Daniel
>