From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
To: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
Gwendal Grignou <gwendal@chromium.org>,
dlunev@chromium.org
Subject: Re: [PATCH v2 2/2] fat: always use dir_emit_dots and ignore . and .. entries
Date: Thu, 27 Jun 2024 05:10:44 +0900 [thread overview]
Message-ID: <87a5j7v517.fsf@mail.parknet.co.jp> (raw)
In-Reply-To: <ZnxwEtmYeZcKopJK@quatroqueijos.cascardo.eti.br> (Thadeu Lima de Souza Cascardo's message of "Wed, 26 Jun 2024 16:46:26 -0300")
Thadeu Lima de Souza Cascardo <cascardo@igalia.com> writes:
>> Unacceptable to change the correct behavior to broken format. And
>> unlikely break the userspace, however this still has the user visible
>> change of seek pos.
>>
>> Thanks.
>>
>
> I agree that if this breaks userspace with a good filesystem or regresses
> in a way that real applications would break, that this needs to be redone.
>
> However, I spent a few hours doing some extra testing (I had already run
> some xfstests that include directory testing) and I failed to find any
> issues with this fix.
>
> If this would break, it would have broken the root directory. In the case
> of a directory including the . and .. entries, the d_off for the .. entry
> will be set for the first non-dot-or-dotdot entry. For ., it will be set as
> 1, which, if used by telldir (or llseek), will emit the .. entry, as
> expected.
>
> For the case where both . and .. are absent, the first real entry will have
> d_off as 2, and it will just work.
>
> So everything seems to work as expected. Do you see any user visible change
> that would break any applications?
First of all, I'm not thinking this is the fix, I'm thinking this as the
workaround of broken formatter (because the windows's fsck also think it
as broken). So very low priority to support.
As said, I also think low chance to break the userspace. However it
changes real offset to pseudo offset. So if userspace saved it to
persistent space, breaks userspace. Unlikely, but I think there is no
value to change the behavior for workaround.
Thanks.
--
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
next prev parent reply other threads:[~2024-06-26 20:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-25 17:51 [PATCH v2 0/2] fat: add support for directories without . and .. entries Thadeu Lima de Souza Cascardo
2024-06-25 17:51 ` [PATCH v2 1/2] fat: ignore . and .. subdirs and always add links to dirs Thadeu Lima de Souza Cascardo
2024-06-25 17:51 ` [PATCH v2 2/2] fat: always use dir_emit_dots and ignore . and .. entries Thadeu Lima de Souza Cascardo
2024-06-25 21:47 ` OGAWA Hirofumi
2024-06-26 19:46 ` Thadeu Lima de Souza Cascardo
2024-06-26 20:10 ` OGAWA Hirofumi [this message]
2024-06-27 12:51 ` Thadeu Lima de Souza Cascardo
2024-06-27 15:28 ` OGAWA Hirofumi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a5j7v517.fsf@mail.parknet.co.jp \
--to=hirofumi@mail.parknet.co.jp \
--cc=cascardo@igalia.com \
--cc=dlunev@chromium.org \
--cc=gwendal@chromium.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox