FWIW, when I've experimented with servers in Pythonista, I also found that the port would often remain "occupied" after stopping the server using the stop button (i. e. KeyboardInterrupt). This was easily fixed by rerunning the server twice - i. e. the first run would fail due to the port being in use, but the second run would work again. (This was a while ago when I was playing around with Python's built-in HTTP server module, no idea if this still happens in current versions, or if this even applies to your situation.)

My wild guess would be that this is some sort of interaction between the "dirty" shutdown via KeyboardInterrupt, the garbage collector, and how Pythonista's interpreter never fully restarts. The KeyboardInterrupt breaks out of the server's main loop, but doesn't close or delete the socket, which is still referenced (indirectly) from a global variable. Rerunning the script clears or overwrites the global, which eventually deletes the socket, but not quick enough for that script run to reuse the port. On the next run, the port is free again and can be reused. (Again, I just came up with this explanation in my head and didn't really verify it. This may be absolute nonsense.)

Hope it's ok to resurrect this old thread.

I'm having this issue also, but I think I've puzzled out what is happening here. Below is my speculation, based on what I've seen during some experimenting.

When arranging the files for "Sort by Date", Editorial doesn't use the "modified" timestamps as shown in the Mac Finder. Instead, it uses the Dropbox "Last upload" timestamp. You can see this in (iPhone) Editorial by tapping the file name at the top of the note, then the Dropbox icon. I don't know a way to see the "last upload" information on the Mac.

For some people, the "last upload" timestamps are in the same order as the "modified" ones. For example, if you made a folder some time ago, and have been slowly adding and changing files, one by one.

However, if you rename a folder, or duplicate it, the Dropbox client on the Mac re-uploads the files within that folder. It does this file by file. I don't know how it determines the upload ordering of the files, but it isn't by modification date. I've just done some careful testing (macOS 10.12.4, Dropbox client 36.4.22), and renaming a folder or duplicating it essentially randomises the ordering of the files as shown in Editorial. I also suspect from earlier tests that doing the same rename / duplication via the Dropbox website will have the same effect.

Actually, I spent a while trying to write an iOS Dropbox notes app in 2013, using the then-current-but-recently-deceased Dropbox v1 API. I didn't find a way for an iOS app to read the file modification timestamps (as shown in the Finder). That information is stored in Dropbox, as it is synchronised between Macs, but I didn't see it exposed in the API. Perhaps things are different in the newer Dropbox APIs... I haven't looked.

I can think of one way to gain control over this beast, but it isn't elegant. If we have a folder where the "last upload" timestamps of the contained files are in a different order to the "modified" ones (eg because the folder has been duplicated / renamed), it would be possible to write a script to create a new folder, then copy (or move) the files in, one at a time, in "modified" timestamp ordering. I'm not sure how precise the "last upload" timestamps are. Editorial shows them to single minute precision. Perhaps the seconds information is stored but not shown. But assuming it's minute resolution only, then the script would have to wait at least a minute between uploads, to preserve the correct ordering. And worse: the script should really wait until the Dropbox client has finished synchronising before starting the next file upload - and I don't see a way for a script to determine if Dropbox sync is in progress or not.

Hope this makes some kind of sense - apologies, because I'm writing in haste. Best wishes all.

@omz, thanks logging out and back into iCloud on my Mac worked!

@cook Cool, tomorrow!