lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1248699785.4618.77.camel@jorg-desktop>
Date:	Mon, 27 Jul 2009 16:03:05 +0300
From:	Jörg Schummer <ext-jorg.2.schummer@...ia.com>
To:	ext OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH take 2][RFC] fat: Save FAT root directory timestamps to
	volume label

On Mon, 2009-07-27 at 13:47 +0200, ext OGAWA Hirofumi wrote:
> Jörg Schummer <ext-jorg.2.schummer@...ia.com> writes:

> > If you don't want this patch.. There's probably good reasons not to take
> > it, especially the amount-of-problem-solving-by-maintenance-cost ratio
> > might be rather low.

> BTW, the patch has several bugs. fat_get_label_entry() doesn't check
> IS_FREE(), is it right? fat_create_label_entry() doesn't initialize all
> timestamp in the case of msdos. spin_lock() usage is wrong. and more...

You got good points there. I'll fix these on the chance that somebody
decides to use it.

> > In summary: If you're not keen on integrating new features which would
> > make Linux look good in the face of shiny Mac OS, there might not be
> > much reason to take it in. Unless we get zillions of people replying now
> > with what wonderful things it would enable them to do.. ;-)
> 
> Yes, we would really want to know whether people want to use this. Is
> there any info from Mac OS people?
> 
> BTW, my thinking is, the option is why default is "rootts=ignore" if
> it's really good?

That's because this feature does not seem to be part of most generally
accepted FAT implementations. So I thought that the default should try
to behave as people would expect FAT to behave: Forget about root dir
timestamps.
On the other hand, except for 'save', none of the options makes 'real'
fs changes, so maybe 'preserve' could be the default. (People who are
used to the 'standard' behaviour should not be harmed by that - once the
bugs are gone, that is..)

> Or 4 rootts=* options is really needed, and what is
> reason? 

I thought 'ignore' should be there in order to provide the
'standard'-FAT behaviour. And 'save' possibly creates a volume label,
which might be not be wanted. But 'load' is not so necessary, indeed.
The behaviour of Mac OS seems to be like 'preserve', btw.

>  Or if it's not good by some reasons, why is it added? ...

The patch was created merely because one guy figured out that FAT can't
save root dir timestamps by default and another guy knew that Mac OS X's
FAT implementation can. So I thought, what the heck, let's enable linux
to do the same thing.

Like mentioned before, this was not created because it would solve many
people's problems. So I seriously do understand if you decide not to
take it in. But still I would appreciate if you could take another look
at my next - hopefully less buggy - version.

Thanks for your comments,
Jörg


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ