We have an utility to process images, built as a standard Applescript droplet (using the code floating around with distinction between folders and individual files).
On one installation (MacBook Pro, macOS 11.5), dragging on a single folder works fine, but when dragging on a selection of 4 files, only 2 get processed. An alert at the beginning of the code confirms that only two files are "taken". Various tests by exclusion show that we have a set of 2 specific files which make the other 2 not being processed. If in the group we drag onto the droplet, one of those files is included, only that one gets taken.
On other installations (iMac, macOS 11.5 or virtual macOS 10.14), this effect does not show up with the same files.
Has anyone heard of such an effect? What can be the cause? What can be done to avoid it?
Any hint is highly appreciated.
Thanks a lot in advance.
As mentioned in a comment, it seems to be a timing issue when feeding the files into the droplet, caused by the Quarantaine flag.
This keword lead to https://superuser.com/questions/1336044/how-to-clear-remove-macos-extended-attributes-recursively-from-a-directory on how to display and remove that flag. After removing it, all files processed properly.
What I will have to do now, is build a little utility which allows to strip that flag, as the issue happens when feeding the droplet.
Related
I am building an openwrt firmware for an old mt7620 board for commercial purpose (captive portal)
I am encountering a strange behaviour when I try to save updated config files. I am trying to figure out the reason.
This is an example of what happens :
1 – FIRST TRIAL :
I compiled an old Chaos Calmer 15.01 openwrt version. From the console, I go to the /overlay/upper/etc/config:
Before reboot
I modify or delete the existing files in the [..]/etc/config/ folder
I create a new file for example "test" in [..]/etc/config/
I create a folder "new_folder" with a file inside
After reboot:
changes are not kept or deleted files are back in [..]/etc/config/ folder
the new file for example "test" is still there
the "new_folder" with its file inside are still there
Finally :
if I delete the new files "test" and "new_folder", after the reboot they are effectively deleted
So to sum-up : only pre-existing files in [..]/etc/config/ folder are reverted back at each reboot.
2 – SECOND TRIAL :
I compiled a firmware of the same version without UCI, when I modify the files in /etc/config/, changes made manually are kept after reboot, except 'wireless' which revert to its initial state.
It seems like some process involving UCI at startup use the original files and not the edited ones.
I took a look to the .sh scripts in /etc/init.d, /etc/rc.d, lib/config, lib/functions, lib/preinit... to see what is going on but its still not clear when and where config files are processed (even after looking at topics on the subject)
3 – THIRD TRIAL :
I managed to compile another firmware based on LEDE 17.01 to see if there are benefits. Unfortunately, I still have the same problem concerning the files in the /etc/config which always revert to their default value.
4 - FINALLY TO SUM-UP :
Is there a way to turn this behaviour off, or is it a kind of 'file protection' towards something that could be seen as 'currupted' by the system ?
Note :
I know that theses versions are very old and some people may recommend to upgrade it.
But, In regards to my constraints, I tried to update to openwrt versions >= 18.06. Each time I have kernel panics even by compiling with the custom changes I made that work with the previous versions (DTS file).
So, I am stuck with it for instance, I prefer having one problem at a time.
Sorry for the long post.
Thanks a lot, by advance, If someone have an idea or have already seen such a situation.
Best Regards.
Edit : Overlay at boot time
Overlay at boot time
I'm using project.vim with VIm to manage large code bases with deep directory structures.
When I switch to another one or create (\C) a new one and do a refresh (\R) project.vim starts displaying messages through the whole process for different directories:
<dir_name> is not a valid directory. [O]K:
I have to press Enter all the time, although the directories exist. I took a look at the code and it checks if the path is a directory. They are.
Maybe there is a fix for this. The directories are under Perforce management, so everything is read-only.
I have to stay at the keyboard and keep pressing Enter for it to go to next directories... For large code bases this is takes a long time.
I contacted the author some time ago, but there was no response.
Did anyone encounter this before?
Could it be the it is bothered by the read-only-ness?
Is there a fix for this?
Thanks
The plugin uses glob() for some of those directory checks, which is affected by the 'wildignore' setting. Try
:set wildignore=
If that fixes the problem (and you have at least Vim version 7.2.51), you can modify the plugin's code to use glob(..., 1) instead.
Alright, here's hopefully my last question about a problem I'm having with my Adalight setup. Anyway, Processing exports two folders, application.windows32, and application.widows64, both of them have a adalight.exe file inside of them, along with lib, and source folders. When I try to run the adalight.exe file, nothing happens, nothing loads, no windows show up, there's no error message. I don't know if it's a problem with my PC, the Processing IDE, or my code (works perfectly if ran through the IDE). I'm not sure if this is enough information, if you need any more I'd be happy to try to provide as much as I can.
I've read the tutorial at https://developer.apple.com/library/mac/documentation/cocoa/Conceptual/SpotlightCoreData/Articles/recordLevel.html so many times now, I can't seem to get it for some reason.
I've tried creating the spotlight importer, manually copying it to ~/Library/Spotlight with no success.
Can anyone be point me to a working sample of CoreData-Spotlight-OSX app? a remotely basic thing would suffice.
The xcode template default-stores .importer in the bundle-resources folder, I've read in other places that it should be in a Library/Spotlight folder if the app is sandboxed.
again, tried & failed.
help!
I’ve written a CoreData / Spotlight importer. It’s always a bit of a struggle, even in the best of times. I wrote mine before those docs, and before they’d written the daemon that writes out the records for you. When the CoreData team first did their version of my solution theirs had several critical bugs which prevented me from using it, so I reported them and switched back to mine—I hope by now they are fixed, but this is something to be aware of.
The other thing to know is that a lot of app-makers (including me) have found Spotlight importing of CoreData records is broken on Mavericks, apparently because of changes in the sandbox. This has been widely reported and I’ve filed a bug. If you’re on Mavericks you might be hitting this problem as well.
But, to debuggin:
The first thing you should do is add some NSLogging to your importer, and check your Console after you make a change to your database. Wait to see if any process that starts with “md” (metadata) reports errors, or if you see the logs your wrote.
Also, do a man mdimport and the run mdimport from the command-line on your plug-in with one of the record files. With mdimport’s -g option you can test your importer wherever it is, and with -d4 you’ll get a lot of debugging info.
You can also do a mdimport -L to see if your importer is being seen by the system.
In general, you need to find out ⑴ does your importer work or does it just crash (by running it directly with mdimporter) ⑵ does the system see your importer and recognize that it’s in charge of stubs with your chosen filetype (mdimport -L) and ⑶ does your importer have permission to see the record files (by running your app and watching the Console).
i was reading this thread ubuntu/linux bash: traverse directory and subdirectories to work with files and i thought maybe it can be twisted a little bit
Can this be set to:
be given a base folder
scan folder + subfolder
collect all files it finds (only images)
pick one randomly
write a symbolic link to /user/share/backgrounds directory (writing the image itself overwriting existing one may work as well)
what i intend is to execute the script upon system shutdown or at set interval so it will change the gdm background image..
this is based on a step to do it manually with this line
sudo ln -s /usr/share/applications/gnome-appearance-properties.desktop /usr/share/gdm/autostart/LoginWindow/
which prompts for the appearance dialog on startup, which writes the link.
Ideally, it would have a GUI to do it at will, and an option to "change it automagically upon restart" which will do the process i described above and add itself to system start, reboot or shutdown sequence.
Since theres no working utility atm for this, it might come handy for some people =)
thanks for your help.
Use Wallpapoz. It can change wallpapers randomly across workspaces and over time.