> Am 06.09.2018 um 04:43 schrieb AKASHI Takahiro <takahiro.aka...@linaro.org>: > >> 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.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. > > Do you accept such an ugly implementation although it yet complies > with fat specification?
It's valid for all intents and purposes, so why not :). > >> 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, that would be great! :) Alex _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
