On Wed, 2007-07-25 at 14:00 +0200, Miklos Szeredi wrote:
> > > > and the way you implement atomic saves there is different (its
> > > > generally backend specific). This makes posix a less than ideal
> > > > high-level API for apps.
> > >
> > > Even if it's not always possible to provide an atomic rename, it's
> > > possible to emulate the POSIX requirements, e.g. by first removing the
> > > target and then renaming, if rename doesn't support atomic overwrite
> > > (as is the case with SFTP used by sshfs).
> > In some cases this is quite problematic though. For instance, if your
> > backing filesystem is a subversion webdav share, then you get all these
> > operations recorded in the version history. Its much nicer to have
> > highlevel operations for apps to use, and implement them in the best way
> > possible for the specific backend.
> > I realize this is not posible with fuse of course, which is why GVFS
> > doesn't use fuse as its main API.
> OK, there's nothing wrong with that. The only pitfall I see is making
> an interface too generic. But if you have primitives like "save file
> with backup" and that sort of thing, it sounds sane.
Yes, its tricky to draw the line at the right place when abstracting
posix. I'm staying pretty close, but making it more abstract/generic
where I think it matters.
This is what I have for save:
GFileOutputStream *g_file_replace (GFile *file,
const char *etag,