OK, nitpicking time.. I love doing this.

Massimiliano Mirra <list / chromatic-harp.com> writes:
> It is also about really treating such entities just like objects in an
> load-modify-commit (or rollback) cycle, like for file I/O (you might
> call this ``filesystem I/O''), rather than doing a lot of atomic
> modify-commit operations (e.g. File.delete('file.txt')) and constantly
> keeping track of what is on disk.

1. Consider separating copy and move-ing. People are used to copying
as an atomic operation. Requiring people to set @copying is an extra
step that is only superflous.

2. Consider creating a grouping class. Just like dbase transaction,
the last COMMIT will #sync every FSE instances in that group. Why not
use Array, you asked. You can, but isn't this nicer:

#delete files specified in the args
Group.add(:delete, "/etc/fstab", "/etc/login")
Group.add(:copy, ["/etc/passwd", "/etc/passwd.bak"], ["/etc/shadow", "/etc/shadow.bak"])
Group.add(:move, ["/tmp/something", "/tmp/somethingelse"], ...)
Group.sync #do the above changes

The advantage of Grouping becomes apparent when you are doing this on
a remote fs: one long instructions vs. multiple short instructions.

What to do with exists??? I don't know. I think it should be left
alone in FSE (i.e., don't make Group support that).

May be this is a YAGNI (You Ain't Gonna Need It), but how about making
a DSE class for directories? Or rather soup-up FSE so that it supports
listing since a dir is a special file.

YS.