macosx file opening / searching problems

[pfile]

a couple of things:

i just found that if a file pathname has a directory named with a leading $, PI seems to want to interpret this as a variable of some kind, so i can not open such a file by dragging the file from the finder to the PI desktop - a file not found error is generated, presumably because the $<dir_name> evaluates to nil, and so the pathname for the file is not correct. opening the file from the native Open File dialog does work, however.

the second is that i'm having trouble with spotlight on AFP-mounted NAS volumes again - trying to search for files using the native Open File dialog from within PI yields no matches if the directory being searched is on an AFP mount.

in the past this problem seemed to be caused by the lack of spotlight metadata for .fits files, and was rectified by installing the Observatory Pro finder plugin which provides native .fits/.xisf support to OSX. however, i just noticed though that on the latest released version of PI, i can not search for any .fits files that are contained on an AFP volume. the finder can successfully find them, so it feels like this problem is somehow different than before.

thanks,

rob

[Juan Conejero]

Hi Rob,

Thank you for your report.

if a file pathname has a directory named with a leading $, PI seems to want to interpret this as a variable of some kind, so i can not open such a file by dragging the file from the finder to the PI desktop

Yes, this happens, and is obviously a bug. This only happens when you drag one or more files to PixInsight's workspace because in this case the files are opened by running an open command from Process Console. The open command performs macro expansions of environment variables automatically for any name starting with a dollar sign, following common shell syntax rules on UNIX.

I can fix this problem by adding a --no-expand-vars command line argument to the open command, which will be used when the workspace triggers an open command after a file drag operation. This will be included in the next version of the core application.

the second is that i'm having trouble with spotlight on AFP-mounted NAS volumes again - trying to search for files using the native Open File dialog from within PI yields no matches if the directory being searched is on an AFP mount.

I don't know how to solve this problem. If you can open these files with Finder and not on file dialogs opened from PixInsight, there is obviously something wrong. One of the main problems here is that native file dialogs on macOS provide very little configuration options programmatically, and even less when used from Qt (none, basically). I have no idea how I can configure spot light search on these dialogs for NAS mounted devices. Spot light works perfectly with the local filesystem, at least on all of my Mac machines, and if the UNIX paradigm is being implemented here (macOS is a certified UNIX platform!), there should be no difference at all for mounted network devices. If you can find any information or coding examples about this, that could help.

[pfile]

thanks for looking at these - i will see if i can find anything about the open file dialog. yes, the search works OK in the finder (though i think it actually worked OK in the finder many versions ago when i first installed the Observatory Pro plugin.) i agree that unix is the king of abstraction and this should just work.

maybe other OSX/nas users can check this to see if it's just me or if it is a widespread problem.

rob

[pfile]

so following up on this - i think it's likely to be just a bug in at least High Sierra's handling of spotlight on remote-mounted AFP volumes.

in the past i had found that just turning indexing on was not enough to keep the OS interested in updating the spotlight data of newly created files. i know apple have been adding more and more sophisticated file modification notification stuff to the kernel and i guess it's just broken for remote volumes. in order to keep the database up to date i've had to manually import my newly created subs every night.

just now i rebooted my machine to apply security updates and PI could not find any files on the remote volume; despite mdctl reporting that indexing was turned on for the volume, it apparently was not; doing mdctl -i on . at the root of the shared volume caused a flurry of activity and after a few minutes, PI was able to find files on the remote volume again. so it looks like the indexing state and/or index itself does not survive a reboot for remotely mounted volumes.

rob