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.aka...@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. 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 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? Alex _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
