Michael Rothwell wrote:
> Rogier Wolff wrote:
>
> > Linus' suggestion of having a mix between a file and a dir is
> > interesting, but is not representable by a normal ext2fs
>
> filesystems that support streams/forks/EAs are _not_
> like ext2, and it seems wrong to make them try to
> squeeze into ext2's shoes.
Right. But HFS isn't like ext2 either. But the "mapping" that the HFS
guys made maps onto regular Posix semantics nicely. Tar is
sufficiently happy that it will tar up a HFS partition good enough to
be able to reconstruct the original (for all practical purposes) if
you unpack it on another HFS partition.
It also works if you unpack it onto an Ext2fs, retar, and then unpack
it on HFS.
This is a nice feature. It is useful.
I'm saying: It's possible to get this right, and I think it's
useful.
I'm arguing: I think it's a feature you really want to try to take
along in your design. Take it along as a requirement.
I'm NOT saying that ext2 should be modified to also have "forks" and
things like that.
> , or
> > TAR. Having to extend the TAR format is a pain in the ass. Losing info
> > when you untar onto an ext2fs is also annoying.
>
> So there will be a "star" utility for streams filesystems,
> which one day will get merged into regular tar. Or "spax"
> or whatever.
Yes. And an unpack/repack cycle on a non-linux machine will fail. And
tar tvf on other machines will also fail, or at least look very funny.
> > A friend of mine has a
> > Linux fileserver that is used to share files between his apple and his
> > windows machine. The current way that atalkd stores files is the same
> > as that HFS exports stuff. This means that everything is
> > interoperable.
> It would be nice to have a universal representation of
> streams/EAs/forks for FSes that support them, without using
> ".LinuxDouble" chicanery. If all EAs are stored in a separate
> directory, I imagine they will be orphaned all the time. I know this
> happens in HFS. I usually walked over to a Mac (when I had Macs) to
> manipulate files, rather than do it from the linux box, because I
> would break the filesystem doing it frm Linux. With the HFS hack, I
> can only move/rename/delete whole directories at a time to avoid
> filesystem corruption. Or tediously go into each .AppleWhatever
> directory, find all the orphaned resources, and move those as well.
Right.
So, as long as the stuff is representable on a normal filesystem, you
get the OPTION of running it off a normal filesystem.
If we go for the suggestion that a file may be both a file and a
directory, then we have the semantics defined to access HFS forks and
NTFS named streams. Neat. But if you want to atalk-serve or smb-serve
such a "full-featured" filesystem from your ext2fs (because your large
fileserver need not be bothered with an NTFS or HFS partition) you're
in trouble. It can't be done.
You can almost trivially write a "shell" that will do
rm .Appledoube/somefile somefile
when you type "rm somefile" .
In your case, if we go with the suggested duality, you wouldn't have
been able to serve the filesystem to the apples. You'd have to create
& mount an HFS filesystem. Then, when you would remove the somefile,
the resource would automatically disappear. Are you sure you want
that?
Oh, about orphaned forks: If you happen to want to serve the apples
from a non-apple filesystem, then you can easily run a nightly deamon
that finds the orphaned forks, and deletes them.
How's this?
find $appefilesystems -name .Appledouble -exec cleanup_resources {} \;
#!/bin/sh
#cleanup_resources -- By REW
cd $1
for i in $*
do
if [ ! -f "../$i" ] ; then
rm "$i"
fi
done
Roger.
-- ** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * Common sense is the collection of * ****** prejudices acquired by age eighteen. -- Albert Einstein ********- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:33 EST