loggedfs на Mac с osxfuse застрял
Я хотел бы регистрировать каждый системный вызов указанного каталога, и я нашел этот репозиторий https://github.com/rflament/loggedfs
Он создает виртуальную файловую систему с предохранителем и регистрирует в ней все, как я хочу.
Я попытался перенести его на Mac, но он использует «трюк», который не работает на OSX. lstat застрял 10с и сбой.
Я хотел бы понять, почему?
Это основная часть моего кода:
// g++ -Wall main.cpp `pkg-config fuse --cflags --libs` -o hello
#define FUSE_USE_VERSION 26
#include <fuse.h>
#include <stdio.h>
#include <string.h>
#include <errno.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
static char *path;
static int savefd;
static int getattr(const char *path, struct stat *stbuf)
{
int res;
char rPath[1024];
strcpy(rPath, "."); strcat(rPath, path);
res = lstat(rPath, stbuf); // Mac stuck here
return (res == -1 ? -errno : 0);
}
static void* loggedFS_init(struct fuse_conn_info* info)
{
fchdir(savefd); close(savefd); return NULL;
}
int main(int argc, char *argv[])
{
struct fuse_operations oper;
bzero(&oper, sizeof(fuse_operations));
oper.init = loggedFS_init;
oper.getattr = getattr;
path = strdup(argv[argc - 1]);
printf("chdir to %s\n", path);
chdir(path);
savefd = open(".", 0);
return fuse_main(argc, argv, &oper, NULL);
}
Решение
Я очень внимательно посмотрел на LoggedFS и проверил его на соответствие POSIX, используя pjdfstest, в результате чего 3 вопроса (или группы вопросов). Я в итоге повторная реализация его в Python, полностью POSIX-совместимый Я еще не тестировал его на OS X, поэтому буду рад получить отзывы;)
«Уловка», о которой вы упоминаете, может быть основной причиной вашей проблемы, хотя я не совсем уверен. Это вызывает фундаментальную проблему, добавляя еще один символ в путь, что приводит к проблемам, когда длина path приближается к PATH_MAX. libfuse уже проходит пути с ведущим / в операции FUSE. Дополнительный . плюс «вводящий в заблуждение» / (корень смонтированной файловой системы, а не «глобальная» корневая папка) — это два символа «слишком много», что эффективно уменьшает максимально допустимую длину пути до PATH_MAX минус 2. Я изучил варианты изменения PATH_MAX и информирования программного обеспечения пользователя земли о меньшем PATH_MAX , который оказалось невозможным.
Однако есть способ обойти. Не закрывайте дескриптор файла savefd в init рутина. Держите его открытым и вместо этого закройте в destroy рутинный, который будет вызываться FUSE, когда файловая система размонтирована. Вы действительно можете использовать savefd для указания путей относительно него. Вы можете использовать fstatat (Linux, OS X / BSD) вместо lstat, Его прототип выглядит так:
int fstatat(int dirfd, const char *pathname, struct stat *buf,
int flags);
Вы должны пройти savefd в dirfd и удалить ведущий / от содержания path прежде чем передать его в pathname,
Другие решения
Других решений пока нет …