On Tue 09 Jan 2024 at 15:30:49 (-0500), Stefan Monnier wrote:
> David Wright [2024-01-09 10:07:26] wrote:
> > but what seems most likely is that the root directory filled up.
> > The size of that is fixed when formatted, at least up to FAT16.
> > Long filenames will eat it up more quickly still.
>
David Wright [2024-01-09 10:07:26] wrote:
> but what seems most likely is that the root directory filled up.
> The size of that is fixed when formatted, at least up to FAT16.
> Long filenames will eat it up more quickly still.
Long file names are actually kept in a (hidden) files, so they don't ea
On Tue, Jan 09, 2024 at 10:57:29AM -0500, Stefan Monnier wrote:
> >>What are you talking about? FAT does not get “overloaded” by long
> >>filenames.
> > Seen it happen;
>
> I have serious doubts about the "it".
>
> > Long filenames, mixed case, and files saved at the beginning of
> > a session of
On Tue, 9 Jan 2024 10:07:26 -0600
David Wright wrote:
Hello David,
>The size of that is fixed when formatted, at least up to FAT16.
>Long filenames will eat it up more quickly still. Create
>subdirectories and the problem goes away.
Yes, this is exactly what I experienced. So not the FAT at fa
On Tue 09 Jan 2024 at 10:57:29 (-0500), Stefan Monnier wrote:
> >>What are you talking about? FAT does not get “overloaded” by long
> >>filenames.
> > Seen it happen;
>
> I have serious doubts about the "it".
>
> > Long filenames, mixed case, and files saved at the beginning of
> > a session of c
>>What are you talking about? FAT does not get “overloaded” by long
>>filenames.
> Seen it happen;
I have serious doubts about the "it".
> Long filenames, mixed case, and files saved at the beginning of
> a session of copying multiple files would be lost because the FAT was
> filled, and overwrit
6 matches
Mail list logo
