[PATCH] erofs-utils: fix `--blobdev=X`
Hongbo Li
lihongbo22 at huawei.com
Sun Apr 27 19:17:28 AEST 2025
On 2025/4/27 15:17, Gao Xiang wrote:
>
>
> On 2025/4/27 15:04, Hongbo Li wrote:
>>
>>
>> On 2025/4/27 10:56, Gao Xiang wrote:
>
> ...
>
>>>>> diff --git a/lib/blobchunk.c b/lib/blobchunk.c
>>>>> index e6386d6..301f46a 100644
>>>>> --- a/lib/blobchunk.c
>>>>> +++ b/lib/blobchunk.c
>>>>> @@ -627,7 +627,8 @@ int erofs_blob_init(const char *blobfile_path,
>>>>> erofs_off_t chunksize)
>>>>> blobfile = erofs_tmpfile();
>>>>> multidev = false;
>>>>> } else {
>>>>> - blobfile = open(blobfile_path, O_WRONLY | O_BINARY);
>>>>> + blobfile = open(blobfile_path, O_WRONLY | O_CREAT |
>>>>> + O_TRUNC | O_BINARY, 0666);
>>>> To maintain consistency, is it better to set the default permission
>>>> to 0644?
>>>
>>> I tend to switch all modes to 0666 around the codebase
>>> in the future, since umask(022) will mask them into 0644.
>>>
>> but 0644 can clearly show which permissions are set (the default umask
>> 022 won't change anything). Or if we need to enforce a specific mode,
>> can we umask to 0 at the beginning instead of relying on the default
>> umask?
>
> see fopen(3): https://man7.org/linux/man-pages/man3/fopen.3.html
>
> In short, I'd like to change all 0644 to 0666 since
> there is no reason to mask off other permissions
> unless umask is also effective.
>
> Or do you have other concerns?
>
>>
>> By the way, I have another doubt (just occurred to me when seeing
>> O_TRUNC, though it might be unrelated to this change): the chunk-based
>> format can't be used together with the "--increase" option. Should we
>> add a warning for that?
>
> Why?
>
Because some formatting options cannot be used in combination (such as
--blobdev --chunksize --incremental=xxx in non-tar mode). But this might
be outside the scope of this patch.
Perhaps we can add the constraints or some explanation to avoid any
misunderstanding later. What's about your opinion?
Thanks,
Hongbo
> Thanks,
> Gao Xiang
>
>>
>> Thanks,
>> Hongbo
>>
>>> Thanks,
>>> Gao Xiang
>
More information about the Linux-erofs
mailing list