Re: [MiNT] mv does delete when fail of fat (was: 1-18-cur trunk stability issues)

[Paul Wratt <paul.wratt@gmail.com>]

you will probably need a MiNT -> Linux drive/partition translation layer

the easiest way to get that is probably from both the fat fs check &
the ext2 fs check utilities

On Thu, Dec 1, 2011 at 8:42 AM, Peter Slegg <p.slegg@scubadivers.co.uk> wrote:
> We do need a more comprehensive undelete tool for Mint that
> can handle FAT32 and longfilenames properly.
>
> I did mention a couple of candidates on this list a few years
> ago and managed to build Photorec but it doesn't recognise the
> mint file systems.
>
> Regards,
>
> Peter
>
>
>
> On Wed, 30 Nov 2011 12:36:47 , Paul Wratt <paul.wratt@gmail.com> wrote:
>> I did some tests years ago at "hiding" files on FAT drives, and how
>> delete and undelete worked. If you only E5 the 1st char (manually) the
>> FAT entries in FAT1 would get trash by CHKDSK (set to free) and you
>> would loose the file (unless you kept another fat list elsewhere and
>> no new files over wrote the data)
>>
>> maybe the fat pointer in the dir listing is zero'd (but that would
>> stop undelete from working), I meant that there could still be valid
>> dir entries in the dir list, even tho the filenames might be invalid
>> to TOS/fs for output, because fs check only for valid entries in the
>> dir list, and that the size recorded there matches the cluster list in
>> the fat. the FAT is only (normally) zero'd with special tool, not on
>> delete
>>
>> I do remember FAT1==FAT2 is not always true, ie not always maintained
>> by OS (and so not usable for its intended purpose, to restore FAT1 -
>> circa 1980)
>>
>> Anyways, it appears the Marks initial problem is mv version related,
>> not fs related
>>
>> Paul
>>
>> 2011/11/30 Vincent Rivière <vincent.riviere@freesbee.fr>:
>> > Paul Wratt wrote:
>> >>
>> >> remember that a deleted file simply has the first char of&hE5
>> >
>> >
>> > No, the FAT entries are freed, too.
>> >
>> > --
>> > Vincent Rivière
>> >
>> >
>>
>>
>
>
>