so i've been thinking... yes it's annoying but there are reasons.
it's a balance. time to change this as well as centralize it
meta info is stuff like the xxx.meta.efm files that can store icon x,y
and width x height (and any number of other things - they are .ini style
files). thumbnails are extra meta files that contain relevant info
that is auto-generated by efm's default backend. they can be large but
as it's auto-generated they are xxx.thumb.efm in these separate files
efm2 will now, if you own the dir and can write to it, store metadata
in /path/to/dir/.efm/xxx.*.efm - so either xxx.meta.efm or xxx.thumb.efm
with xxx being the matching filename in the dir. yes - this means efm
will create .efm dirs in dirs you own. first - it's a hidden dir - what are
you doing listing ALL files all the time and seeing it? dot files are
hidden by default and convention for a reason. to allow extra metadata
to live in your fs without you seeing it all the time! secondly - the
data has to go somewhere and 'find ~/ -name .efm -delete' is about as
easy (for such advanced users who are doing ls -a opr using find etc.)
as 'rm -rf ~/.e/e/efm/*' if you want to nuke the metadata.
now why do this? the principle of least surprise. you are a regular joe
user who uses a filemanager and then you run some tool (from the gui)
to zip/tar up some dir tree then unpack it somewhwre else... if efm
doesnt store the data in that tree then then unpacked files lose their
metadata. "suprise" for a user that they lost data they see visually.
surprising the user less if possible by design is a good thing.
creation of magic files automatically is also highly common - vim and
emacs save new file~ files - and people accept it because it's been
that way forever.. so a .efm dir is definitely directly in keeping
with history, precedent and the principle of least surprise. not to
mention .git, CVS and .svn dirs too.
there is a long history of this elsewhere too. windows has Thumbs.db
files. Macos has .DS_Store. AmigaOS had filename.info files. Good old
xv had .xvpics dirs. it's almost expected. the reason this is done is
to keep the metadata alongside the files where possible for least
surprise.
efm can also store it in ~/.e/e/efm/meta/ too. it will do this when
the above conditions are not met (you don't own the dir or you cannot
write to it). as the decision is made in one place with one function
to decide if you can write, this is a single point now where policy
could change this and ONLY EVER write metadata in ~/.e/e/efm/mneta no
matter if you can write or not. but that'd have to be an opt-in as it
then increases surprise loss of data for users as above. and i'ts a
"deal with it later" thing.
note - it may seem silly now like "just for some stupid thumbnails" or
"stupid x/y location i never use". this WILL be used for more later.
e.g. flagging files and/or dirs for use with rsync tooling later to
sync files/dirs or syncthing or backup tools to auto-backup changes
and so on etc. - actual functionality where you want more and more
metadata stored in your filesys5tem so tools know what to do with your
files.
if i could use xattrs for this... i would. but i can't. they don't
port between filesystems. they can't be set on symlinks and more. if
i could use xattrs - you'd never SEE this data and wouldn't complain
but as xattrs are limited this has to be stored in actual files. efm
will "enforce" hiding of these dirs as they are highly advanced stuff
in there and the only way you should (unless you like living on the
cmdline and poking around) deal with these is via the efm ui
(implicitly as you browse about and do things). if you live on a
cmdline and like to poke - you can.
oh .. i forgot.. this also adds the initla "mv" implementation... it
doesn't handle all errors and cases yet... no status info and so on...
now if u drop over a dir in a dir a sub-open process will spin up to
handle that sub dir and be passed relevant dnd cmd's
right now the open doesnt DO anything ... but there are just some
XXX's there left to fill in the doing.
also the sub-opens don't know when to close/end - there is a XXX for
that.
Carsten Haitzler