Hi Corinna, On Mon, 9 Dec 2024 16:26:53 +0100 Corinna Vinschen wrote: > On Dec 9 22:57, Takashi Yano wrote: > > On Mon, 9 Dec 2024 22:44:00 +0900 > > Takashi Yano wrote: > > > On Mon, 9 Dec 2024 12:11:56 +0100 > > > Corinna Vinschen wrote: > > > > init_reopen_attr() uses the "open by handle" functionality as in the > > > > Win32 API ReOpenFile(). It only does so if the filesystem supports it. > > > > Samba usually does, so it's not clear to me why pc.init_reopen_attr() > > > > fails for you. > > > > > > I didn't mean pc.init_reopen_attr() failed. Just I was no idea > > > for what handle to be passed. > > > > > > > > What handle should I pass to pc.init_reopen_attr()? > > > > > > > > You could pass pc.handle(). Is pc.handle() in this scenario NULL, > > > > perhaps? > > > > > > I have tried pc.handle() and suceeded. Thanks for advice! > > > > No! pc.handle() sometimes seems to be NULL.... > > Can you please figure out in which scenario it's NULL? Theoretically > the function shouldn't even be called in this case.
This seems to happen when check_file_access() is called from av::setup() (spawn.cc:1237) called from child_info_spawn::worker() (spawn.cc:358). There are two other check_file_access() in spawn.cc (L156, L1132), but I don't confirm them if they are the same. -- Takashi Yano <takashi.y...@nifty.ne.jp>
