Blocking readFileAtPath calls and getting attributes for this file

[Roman Sidorakin]

Hello everyone.

I am writing app, that uses osxfuse 3.7.1. I'm using obj-c framework in my app. Target OSX are 10.12 and 10.13.

The idea is when user opens some file (double clicks) inside mounted drive, then download from server should be started. After downloading it will be opened completelly. What I'm doing to achive this - I'm blocking 'readFileAtPath' calls, until requested offset & size will be downloaded. This part works correctly.

But there is a side effect. If there are some 'read' calls are blocked and user right clicks on this file, or browses mounted drive, then Finder.app hangs. Seems like, when 'readFileAtPath' calls are blocked, then other calls like 'attributesOfItemAtPath' (getting attributes) and 'contentsOfDirectoryAtPath' (listing) are blocked too. 

As a result, when 'read' calls are blocked, Finder can't get attributes for file or request content of directory and become freezed. I've also tried to reproduce it with hello_ll.c example and saw the same behavior. 

I've also simulated this situation with console app, instead of Finder. Inside console app, I am reading a file and periodically getting attributes for it. And when read call is blocked (waits until requested data will be downloaded) I can't get attributes for it. Seems like at this time kext doesn't send requests for attributes to user space.

So, my question is: does it possible to receive requests from kernel space independently? For example, when 'read' is blocked, I want to receive requests for attributes and respond to them. If it's possible by modifying kext, can you point me to the problem or part of code, that responsible for it?

I've tried different mount options and nothing changed. I've also looked at the topics in google groups and found some ideas about returning -EINTR error for 'read' calls, that we are not able to respond now. I've tried it, but found, that it works not for all formats of files. Other words, seems like it depends from associated app, that opens this file and if it doesn't expect EINTR, then it just closes the file without retrying. For example when I'm opening image using Preview.app and returning EINTR in read call, then it tries read this chunk again and then closes the file. But when I am opening text file with TextEdit.app, then I can return -EINTR infinitely and read calls will be restarted. Looks like it's not an option for me, because it depends from app, that opens file.

It's an kind of blocker for me now and I am trying to understand if it's possible to change messaging between kernel space and user space to make it non blocking.

I will be happy for every response or guidance. Thank you.

[Victor]

Hi Raman, i have few similar  problems in my project. Any advise ? 

среда, 27 сентября 2017 г., 13:51:49 UTC+3 пользователь Roman Sidorakin написал:

[Nickolay Olshevsky]

Hi Roman and Victor,
Basically, you should use multithreaded approach.
And another advice - get attributes call should as fast as possible
since Finder sends it very often.

> --
> You received this message because you are subscribed to the Google
> Groups "OSXFUSE" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to osxfuse-grou...@googlegroups.com
> <mailto:osxfuse-grou...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.


--
Best regards,
Nickolay Olshevsky

[Roman Sidorakin]

Hello, Nickolay.

I am using osxfuse.framework and creating filesystem with isThreadSafe = YES;

[[GMUserFileSystem alloc] initWithDelegate:delegate isThreadSafe:YES];

And all callbacks from osxfuse are delivering in different threads. It means, that I am using multithreaded approach.

четверг, 5 октября 2017 г., 18:03:53 UTC+3 пользователь Nickolay Olshevsky написал:

> <mailto:osxfuse-group+unsub...@googlegroups.com>.

[Nickolay Olshevsky]

Hi Roman,
Sorry, it seems I misundestood source of problem.
Generally, you should not block all read requests since Finder sends a
lot of them. At least, to build file previews. Instead you should do
some queueing of download requests, and download larger chunks then
Finder requests. Also it could be correct to wait for a few seconds for
download and if it doesn't happen - return zero or error result for read
request.

>
> Hello, Nickolay.
> I am using osxfuse.framework and creating filesystem with isThreadSafe =
> YES;
>

> [[GMUserFileSystemalloc] initWithDelegate:delegateisThreadSafe:YES];

>
>
> And all callbacks from osxfuse are delivering in different threads. It
> means, that I am using multithreaded approach.

> *
> *четверг, 5 октября 2017 г., 18:03:53 UTC+3 пользователь Nickolay

> > an email to osxfuse-grou...@googlegroups.com <javascript:>
> > <mailto:osxfuse-grou...@googlegroups.com <javascript:>>.

> > For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

>
>
> --
> Best regards,
> Nickolay Olshevsky
>

> --
> You received this message because you are subscribed to the Google
> Groups "OSXFUSE" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to osxfuse-grou...@googlegroups.com

> <mailto:osxfuse-grou...@googlegroups.com>.