Sorry, I know nothing about windows internals, so can’t help with winsfp. Maybe someone else knows the answer?
As for the API questions what I was trying to say is that (again on Linux since I don’t use windows and know nothing about it) you would interact with it by listing files, creating files, read and writing files, and deleting files. All that through the normal OS mechanisms so no special extra API would be needed. Since SeaDrive runs as a filesystem any program can work with it on those terms.
I don’t think I would use the seafile client for this use on windows. Windows has unique ideas about how file access should work. On windows you can get sync errors if seafile tries to read from a file before your program has finished writing to it (or for some reason still has the file open). This behavior of only allowing one program to use a file at a time also caused us to see sync errors when backups were running, and even sometimes when Word crashed with a file open (somehow locking it open until the next reboot). Maybe you know some way around that problem (I will admit, my team didn’t even try since we weren’t paid to support the windows users), but if not it might be best to avoid those problems by sticking to seadrive.
In Linux by default (I think this is configurable) fuse filesystems mounted by a normal user are only accessible to that user, regardless of file permissions. This is why I was saying you would need to have your program and SeaDrive run with the same user id. Again no idea if or how that applies to windows.
And to clear up what I was saying about accessing the files, I meant permissions on at the filesystem level. AFAIK seafile doesn’t preserve any file permissions or ACLs or even ownership metadata. When a file is sent to the server it becomes a file owned by the owner of the library (by virtue of being in the library). And the opposite is true. If the client is logged in as user A, and B shared a file to A, the client program will sync it to the local system where it is then created and owned (from the point of view of the local FS) by the user who is running the client. If it was read-only on A’s machine it won’t be when it gets to B’s.