All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
To: Pavel Machek <pavel@ucw.cz>
Cc: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>,
	dosfstools <daniel@debian.org>, mtools <Alain@linux.lu>,
	linux-kernel@vger.kernel.org
Subject: Re: End of FAT directories
Date: Thu, 28 Apr 2011 15:43:05 +0200	[thread overview]
Message-ID: <1303998185.8188.18.camel@localhost> (raw)
In-Reply-To: <20110428132551.GA5701@ucw.cz>

Am Donnerstag, den 28.04.2011, 15:25 +0200 schrieb Pavel Machek:
> > >  For overwriting the
> > > zeroed entry, why we have to check all entries until see next zeroed
> > > (yeah, now, we allowed the crappy data after zeroed)?
> > My point was not about checking all entries until the next zeroed entry,
> > which is overcomplicating stuff. I meant that if we hit the end (i.e.
> > the first zeroed entry) when searching for free slots, in that case we
> > just clear the one entry directly following the inserted entries. This
> > makes sure that no files magically appear. I *do* understand that
> This sounds like a good idea, and costs nothing. I hope we can
> convince Ogawa...

I am going to implement that and publish a patch. If the patch is clean
enough, maybe we can convince him. But the freedom of open source can't
prevent me from using a patch like that, of course. And maybe it also
helps when the patch gets some testing.

> > I think the *most* important fact is to have at least dosfsck and linux
> > consistent about directories with trailing garbage. So I won't even try
> > to submit a patch to the Linux kernel that stops reading at the first
> > unused directory entry if dosfsck will not accept to stop reading at the
> > first unused directory entry.
> They should *not* be consistent.
> 
> Kernel should stop at zero invalid entry.
> 
> fsck should consider any garbage past zero entry as an error, and zero
> it out. (Complaining about duplicate blocks is unhelpful but better
> than nothing.  It should really zero the garbage out.)

In fact, what you describe is something I would call "consistent". I was
not implying that kernel and dosfsck should do exactly the same thing,
but I was implying that the kernel and dosfsck should either both or
none consider entries past the gap as existing file. Current state is:
both consider past-gap entries valid. Your described state will be: none
consider past-gap entries valid. The behaviour you describe is exactly
what I would imagine as best way to go. Maybe fsck should ask for "shift
post-gap entries/create a dummy deleted entry" vs. "clear post-gap
entries".

Regards,
  Michael Karcher



  reply	other threads:[~2011-04-28 13:42 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-22 18:48 End of FAT directories Michael Karcher
2011-04-22 18:51 ` End of FAT directories (added missing reference) Michael Karcher
2011-04-22 20:40 ` End of FAT directories OGAWA Hirofumi
2011-04-22 21:56   ` Michael Karcher
2011-04-23  0:06     ` OGAWA Hirofumi
2011-04-23 11:38       ` Michael Karcher
2011-04-23 13:46         ` OGAWA Hirofumi
2011-04-28 13:25         ` Pavel Machek
2011-04-28 13:43           ` Michael Karcher [this message]
2011-04-28 15:44             ` OGAWA Hirofumi
2011-06-28 23:09               ` Alain Knaff
2011-04-28 20:51             ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1303998185.8188.18.camel@localhost \
    --to=kernel@mkarcher.dialup.fu-berlin.de \
    --cc=Alain@linux.lu \
    --cc=daniel@debian.org \
    --cc=hirofumi@mail.parknet.co.jp \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.