From mboxrd@z Thu Jan  1 00:00:00 1970
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
Date: Thu, 6 Sep 2018 11:43:46 +0900
Subject: [U-Boot] [PATCH v2 18/23] efi_loader: implement a pseudo "file
	delete"
In-Reply-To: <8176d631-072a-67c9-5792-0aa3d0e0152c@suse.de>
References: <20180904074948.18146-1-takahiro.akashi@linaro.org>
 <20180904074948.18146-19-takahiro.akashi@linaro.org>
 <98202c7d-501c-e886-900f-b3b561b11fa3@suse.de>
 <20180905025111.GE18483@linaro.org>
 <8176d631-072a-67c9-5792-0aa3d0e0152c@suse.de>
Message-ID: <20180906024345.GH18483@linaro.org>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On Wed, Sep 05, 2018 at 10:22:07AM +0200, Alexander Graf wrote:
> 
> 
> On 05.09.18 04:51, AKASHI Takahiro wrote:
> > On Tue, Sep 04, 2018 at 11:16:38AM +0200, Alexander Graf wrote:
> >>
> >>
> >> On 04.09.18 09:49, AKASHI Takahiro wrote:
> >>> This patch is necessary to run SCT.efi (UEFI Self-Certification Test).
> >>> Returning EFI_SUCCESS can cheat SCT execution.
> >>>
> >>> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> >>
> >> How hard would it be to implement a real delete instead?
> > 
> > Good question.
> > The hardest part of implementation, I believe, is about handling
> > nasty long file names in a directory, in particular, when
> > directory entries which comprise a single LFN extend across two clusters.
> > In this case, all the entries must be deleted first, and then go back
> > to the first one and modify it. Due to a current simple buffering of
> > cluster (only one cluster buffer a time), some tweak is necessary.
> > In addition, if there is an already-deleted entry ahead of the given file,
> > we need further rewind directory entries and update the "new" last valid
> > one to mark it as so.
> > Those kind of things would make the implementation a bit complicated
> > rather than simple as expected.
> > 
> > So unless 'real' delete is a must for anything, I'm lukewarm to
> > work on it.
> > 
> > # I admit that we don't have to have this patch just if *delete* returns
> > successfully without doing anything.
> 
> I think both truncate-to-zero (this patch) and
> report-success-when-failure (suggested patch) are hacks that shouldn't
> really go upstream that way unfortunately.
> 
> The way I read the long file name definitions, I think it should be
> perfectly ok to only remove the short file name directory entry.

Do you accept such an ugly implementation although it yet complies
with fat specification?

> Sure,
> we're leaking a few directory entries for the LFN, but I don't think
> that's too bad. Any fsck should be able to find those later on...

As I said in my cover-letter, fsck would complain any way.

> As for how to delete the entry without rewinding directory entries, you
> can just set name[0]=DELETED_FLAG; to indicate that the SFN is deleted, no?

Yes if DELETED_FLAG=0x5e and if we ignore the specific case where
name[0] be 0x00, which means the entry is the *first* invalid one.
(again, the latter would not be mandatory in term of compatibility.)

Since I have already had the code, "real" delete will be put in my next
version if nobody has concerns on this simple implementation.

Thanks,
-Takahiro AKASHI

> 
> Alex