This bizarre thing has just started happening on my Mac which I don't understand. New .png files copied into ~/Desktop are being deleted within 10 seconds of being placed there.
It doesn't have happen with .txt files. It doesn't happen with .png files that are actually text files. It does happen with .txt or .bin files that are actually .png files (by contents). It doesn't happen with any files that are copied into subfolders of the Desktop.
The Desktop is linked to iCloud, but always has been. I haven't changed any iCloud related settings. I have DropBox installed in a different account on the same machine, but that account in not logged in and DropBox is not running.
Can anyone explain what is going on and why it just started happening?
Here is the test script:
#!/bin/bash
do_it() {
date;
cp $1 Desktop/;
count=15;
while test $count -gt 0 && sleep 1; do
let count=count-1;
echo "$(date) $(ls Desktop/$(basename $1))";
done;
}
run() {
for n in desktop.png desktop.txt desktop.zero.bin desktop-png.bin desktop-png.txt; do
do_it Documents/$n
done;
}
run
And here is the output - notice how files that contain .png content are been moved or deleted by something but text files and binary files that don't contain PNGs are not being moved or deleted.
Thu 14 May 2020 15:09:20 AEST
Thu 14 May 2020 15:09:21 AEST Desktop/desktop.png
Thu 14 May 2020 15:09:22 AEST Desktop/desktop.png
Thu 14 May 2020 15:09:23 AEST Desktop/desktop.png
Thu 14 May 2020 15:09:24 AEST Desktop/desktop.png
Thu 14 May 2020 15:09:25 AEST Desktop/desktop.png
Thu 14 May 2020 15:09:26 AEST Desktop/desktop.png
Thu 14 May 2020 15:09:27 AEST Desktop/desktop.png
Thu 14 May 2020 15:09:28 AEST Desktop/desktop.png
ls: Desktop/desktop.png: No such file or directory
Thu 14 May 2020 15:09:29 AEST
ls: Desktop/desktop.png: No such file or directory
Thu 14 May 2020 15:09:30 AEST
ls: Desktop/desktop.png: No such file or directory
Thu 14 May 2020 15:09:31 AEST
ls: Desktop/desktop.png: No such file or directory
Thu 14 May 2020 15:09:32 AEST
ls: Desktop/desktop.png: No such file or directory
Thu 14 May 2020 15:09:33 AEST
ls: Desktop/desktop.png: No such file or directory
Thu 14 May 2020 15:09:34 AEST
ls: Desktop/desktop.png: No such file or directory
Thu 14 May 2020 15:09:36 AEST
Thu 14 May 2020 15:09:37 AEST
Thu 14 May 2020 15:09:38 AEST Desktop/desktop.txt
Thu 14 May 2020 15:09:39 AEST Desktop/desktop.txt
Thu 14 May 2020 15:09:40 AEST Desktop/desktop.txt
Thu 14 May 2020 15:09:41 AEST Desktop/desktop.txt
Thu 14 May 2020 15:09:42 AEST Desktop/desktop.txt
Thu 14 May 2020 15:09:43 AEST Desktop/desktop.txt
Thu 14 May 2020 15:09:44 AEST Desktop/desktop.txt
Thu 14 May 2020 15:09:45 AEST Desktop/desktop.txt
Thu 14 May 2020 15:09:46 AEST Desktop/desktop.txt
Thu 14 May 2020 15:09:47 AEST Desktop/desktop.txt
Thu 14 May 2020 15:09:48 AEST Desktop/desktop.txt
Thu 14 May 2020 15:09:49 AEST Desktop/desktop.txt
Thu 14 May 2020 15:09:50 AEST Desktop/desktop.txt
Thu 14 May 2020 15:09:51 AEST Desktop/desktop.txt
Thu 14 May 2020 15:09:52 AEST Desktop/desktop.txt
Thu 14 May 2020 15:09:53 AEST
Thu 14 May 2020 15:09:54 AEST Desktop/desktop.zero.bin
Thu 14 May 2020 15:09:55 AEST Desktop/desktop.zero.bin
Thu 14 May 2020 15:09:56 AEST Desktop/desktop.zero.bin
Thu 14 May 2020 15:09:57 AEST Desktop/desktop.zero.bin
Thu 14 May 2020 15:09:58 AEST Desktop/desktop.zero.bin
Thu 14 May 2020 15:09:59 AEST Desktop/desktop.zero.bin
Thu 14 May 2020 15:10:00 AEST Desktop/desktop.zero.bin
Thu 14 May 2020 15:10:01 AEST Desktop/desktop.zero.bin
Thu 14 May 2020 15:10:02 AEST Desktop/desktop.zero.bin
Thu 14 May 2020 15:10:03 AEST Desktop/desktop.zero.bin
Thu 14 May 2020 15:10:04 AEST Desktop/desktop.zero.bin
Thu 14 May 2020 15:10:05 AEST Desktop/desktop.zero.bin
Thu 14 May 2020 15:10:06 AEST Desktop/desktop.zero.bin
Thu 14 May 2020 15:10:07 AEST Desktop/desktop.zero.bin
Thu 14 May 2020 15:10:08 AEST Desktop/desktop.zero.bin
Thu 14 May 2020 15:10:09 AEST
Thu 14 May 2020 15:10:10 AEST Desktop/desktop-png.bin
Thu 14 May 2020 15:10:11 AEST Desktop/desktop-png.bin
Thu 14 May 2020 15:10:12 AEST Desktop/desktop-png.bin
Thu 14 May 2020 15:10:13 AEST Desktop/desktop-png.bin
Thu 14 May 2020 15:10:14 AEST Desktop/desktop-png.bin
Thu 14 May 2020 15:10:15 AEST Desktop/desktop-png.bin
Thu 14 May 2020 15:10:16 AEST Desktop/desktop-png.bin
Thu 14 May 2020 15:10:17 AEST Desktop/desktop-png.bin
ls: Desktop/desktop-png.bin: No such file or directory
Thu 14 May 2020 15:10:18 AEST
ls: Desktop/desktop-png.bin: No such file or directory
Thu 14 May 2020 15:10:20 AEST
ls: Desktop/desktop-png.bin: No such file or directory
Thu 14 May 2020 15:10:21 AEST
ls: Desktop/desktop-png.bin: No such file or directory
Thu 14 May 2020 15:10:22 AEST
ls: Desktop/desktop-png.bin: No such file or directory
Thu 14 May 2020 15:10:23 AEST
ls: Desktop/desktop-png.bin: No such file or directory
Thu 14 May 2020 15:10:24 AEST
ls: Desktop/desktop-png.bin: No such file or directory
Thu 14 May 2020 15:10:25 AEST
Thu 14 May 2020 15:10:26 AEST
Thu 14 May 2020 15:10:27 AEST Desktop/desktop-png.txt
Thu 14 May 2020 15:10:28 AEST Desktop/desktop-png.txt
Thu 14 May 2020 15:10:29 AEST Desktop/desktop-png.txt
Thu 14 May 2020 15:10:30 AEST Desktop/desktop-png.txt
Thu 14 May 2020 15:10:31 AEST Desktop/desktop-png.txt
Thu 14 May 2020 15:10:32 AEST Desktop/desktop-png.txt
Thu 14 May 2020 15:10:33 AEST Desktop/desktop-png.txt
ls: Desktop/desktop-png.txt: No such file or directory
Thu 14 May 2020 15:10:34 AEST
ls: Desktop/desktop-png.txt: No such file or directory
Thu 14 May 2020 15:10:35 AEST
ls: Desktop/desktop-png.txt: No such file or directory
Thu 14 May 2020 15:10:36 AEST
ls: Desktop/desktop-png.txt: No such file or directory
Thu 14 May 2020 15:10:37 AEST
ls: Desktop/desktop-png.txt: No such file or directory
Thu 14 May 2020 15:10:38 AEST
ls: Desktop/desktop-png.txt: No such file or directory
Thu 14 May 2020 15:10:39 AEST
ls: Desktop/desktop-png.txt: No such file or directory
Thu 14 May 2020 15:10:40 AEST
ls: Desktop/desktop-png.txt: No such file or directory
Thu 14 May 2020 15:10:41 AEST
Update: thanks to Joseph I installed this simple audit tool and discovered that it is the "bird" process renaming a file. This "bird" process is associated with iCloud and sure enough when I look into the restored files page on iCloud I can see the files that are disappearing.
So, the next question is: why iCloud doing this and how do I tell it to stop?
Related
I'm using elasticdump and got weird error
Mon, 14 Nov 2022 14:42:21 GMT | starting dump
Mon, 14 Nov 2022 14:42:22 GMT | got 10 objects from source elasticsearch (offset: 0)
Mon, 14 Nov 2022 14:42:22 GMT | sent 10 objects to destination file, wrote 10
Mon, 14 Nov 2022 14:42:22 GMT | Error Emitted => This and all future requests should be directed to the given URI.
Mon, 14 Nov 2022 14:42:22 GMT | Error Emitted => This and all future requests should be directed to the given URI.
Mon, 14 Nov 2022 14:42:22 GMT | Total Writes: 0
Mon, 14 Nov 2022 14:42:22 GMT | dump ended with error (get phase) => MOVED_PERMANENTLY: This and all future requests should be directed to the given URI.
It successfully moved 10 objects and stopped
--input-index is for a different use case.
Try with just --input like this
elasticdump --input=http://localhost/dev_index --output=test2.json
I'm currently building a versioning pipeline that would automatically promote tags based on date. I am able to return all my tags with this command: git for-each-ref --format="%(refname:short) | %(creatordate)" "refs/tags/*"
Which outputs something like this:
v1.0.0 | Mon Jan 24 14:36:19 2022 -0600
v1.1.0 | Mon Jan 24 14:37:06 2022 -0600
v1.1.1 | Mon Jan 24 14:40:39 2022 -0600
v1.1.2 | Tue Jan 25 17:47:32 2022 +0000
v1.1.3 | Tue Jan 25 21:20:03 2022 +0000
v1.1.4 | Tue Jan 25 21:22:40 2022 +0000
v1.2.0 | Tue Jan 25 21:24:08 2022 +0000
v1.3.0 | Tue Jan 25 21:52:28 2022 +0000
I'm looking to take this output and filter it based on current date. So for example if I want all tags created after Jan 24, I'd need to filter this output to only return the tags created from the 25th and beyond.
I'm thinking awk could help with this but I'm uncertain.. Any tips would be great!
I use an apache storm topology on a cluster of 8+1 machines. The date on these machines is not the same and we may have more than 5 minutes of difference.
preprod-storm-nimbus-01:
Thu Feb 25 16:20:30 GMT 2016
preprod-storm-supervisor-01:
Thu Feb 25 16:20:32 GMT 2016
preprod-storm-supervisor-02:
Thu Feb 25 16:20:32 GMT 2016
preprod-storm-supervisor-03:
Thu Feb 25 16:14:54 UTC 2016 <<-- this machine is very late :(
preprod-storm-supervisor-04:
Thu Feb 25 16:20:31 GMT 2016
preprod-storm-supervisor-05:
Thu Feb 25 16:20:17 GMT 2016
preprod-storm-supervisor-06:
Thu Feb 25 16:20:00 GMT 2016
preprod-storm-supervisor-07:
Thu Feb 25 16:20:31 GMT 2016
preprod-storm-supervisor-08:
Thu Feb 25 16:19:55 GMT 2016
preprod-storm-supervisor-09:
Thu Feb 25 16:20:30 GMT 2016
Question:
Is the storm topology affected by this non-synchronization?
Note: I know that synchronizing is better, but the sysadmins won't do it without proving them proofs/reasons that they have to do it. Do they really have to do it, "for the topology's sake" :) ?
Thanks
It depends on the computation you are doing... It might have an effect on your result if you do time based window operations. Otherwise, it doesn't matter.
For Storm as an execution engine it has no effect at all.
Jmeter is taking always the same time to finish remote test. The jmx script is simple and there is no time configured on it, and there are just one request (only 84ms in local test).
It happens only on remote test, in local test is ok.
Starting the test on host x.x.x.x # Thu Aug 14 09:31:43 BRT 2014 (1408019503091)
Finished the test on host x.x.x.x # Thu Aug 14 09:34:43 BRT 2014 (1408019683082)
Starting the test on host x.x.x.x # Thu Aug 14 09:35:53 BRT 2014 (1408019753107)
Finished the test on host x.x.x.x # Thu Aug 14 09:38:53 BRT 2014 (1408019933091)
Starting the test on host x.x.x.x # Thu Aug 14 09:40:33 BRT 2014 (1408020033110)
Finished the test on host x.x.x.x # Thu Aug 14 09:43:33 BRT 2014 (1408020213100)
Starting the test on host x.x.x.x # Thu Aug 14 10:03:23 BRT 2014 (1408021403158)
Finished the test on host x.x.x.x # Thu Aug 14 10:06:23 BRT 2014 (1408021583154)
Starting the test on host x.x.x.x # Thu Aug 14 10:07:53 BRT 2014 (1408021673181)
Finished the test on host x.x.x.x # Thu Aug 14 10:10:53 BRT 2014 (1408021853164)
Starting the test on host x.x.x.x # Thu Aug 14 10:25:23 BRT 2014 (1408022723204)
Finished the test on host x.x.x.x # Thu Aug 14 10:28:23 BRT 2014 (1408022903204)
Starting the test on host x.x.x.x # Thu Aug 14 10:33:13 BRT 2014 (1408023193224)
Finished the test on host x.x.x.x # Thu Aug 14 10:36:53 BRT 2014 (1408023413225)
I have a single instance of MongoDB 2.4.8 running on Windows Server 2012 R2. MongoDB is installed as a Windows Service. I have journalling enabled.
The MongoDB documentation suggests that the MongoDB service should just be shut down via the Windows Service Control Manager:
net stop MongoDB
When I did this recently, the following was logged and I ended up with a non-zero byte mongod.lock file on disk. (I used the --repair option to fix this but it turns out this probably wasn't necessary as I had journalling enabled.)
Thu Nov 21 11:08:12.011 [serviceShutdown] got SERVICE_CONTROL_STOP request from Windows Service Control Manager, will terminate after current cmd ends
Thu Nov 21 11:08:12.043 [serviceShutdown] now exiting
Thu Nov 21 11:08:12.043 dbexit:
Thu Nov 21 11:08:12.043 [serviceShutdown] shutdown: going to close listening sockets...
Thu Nov 21 11:08:12.043 [serviceShutdown] closing listening socket: 1492
Thu Nov 21 11:08:12.043 [serviceShutdown] closing listening socket: 1500
Thu Nov 21 11:08:12.043 [serviceShutdown] shutdown: going to flush diaglog...
Thu Nov 21 11:08:12.043 [serviceShutdown] shutdown: going to close sockets...
Thu Nov 21 11:08:12.043 [serviceShutdown] shutdown: waiting for fs preallocator...
Thu Nov 21 11:08:12.043 [serviceShutdown] shutdown: lock for final commit...
Thu Nov 21 11:08:12.043 [serviceShutdown] shutdown: final commit...
Thu Nov 21 11:08:12.043 [conn1333] end connection 127.0.0.1:51612 (18 connections now open)
Thu Nov 21 11:08:12.043 [conn1331] end connection 127.0.0.1:51610 (18 connections now open)
...snip...
Thu Nov 21 11:08:12.043 [conn1322] end connection 10.1.2.212:53303 (17 connections now open)
Thu Nov 21 11:08:12.043 [conn1337] end connection 127.0.0.1:51620 (18 connections now open)
Thu Nov 21 11:08:12.839 [serviceShutdown] shutdown: closing all files...
Thu Nov 21 11:08:14.683 [serviceShutdown] Progress: 5/163 3% (File Closing Progress)
Thu Nov 21 11:08:16.012 [serviceShutdown] Progress: 6/163 3% (File Closing Progress)
...snip...
Thu Nov 21 11:08:52.030 [serviceShutdown] Progress: 143/163 87% (File Closing Progress)
Thu Nov 21 11:08:54.092 [serviceShutdown] Progress: 153/163 93% (File Closing Progress)
Thu Nov 21 11:08:55.405 [serviceShutdown] closeAllFiles() finished
Thu Nov 21 11:08:55.405 [serviceShutdown] journalCleanup...
Thu Nov 21 11:08:55.405 [serviceShutdown] removeJournalFiles
Thu Nov 21 11:09:05.578 [DataFileSync] ERROR: Client::shutdown not called: DataFileSync
The last line is my main concern.
I'm also interested in how MongoDB is able to take longer to shut down than Windows normally allows for service shutdown? At what point is it safe to shut down the machine without checking the log file?