Sort by Date not working in Editorial

aaljr

In Editorial 1.2.1, Sort by Date displays the files that are stored in Dropbox in an apparent random order with no correlation to the date modified shown in the OS X Finder.

It seems to work fine for local storage, but not when stored in Dropbox.

Is this is a known issue?

Thanks,

AAL

ekul

I just discovered this same issue. Working with a huge list of notes on Dropbox, the search and highlighting is really amazing, but the 'date' sort order (while apparently not random) is definitely not chronological.

Some lists are only usable by date (syncing with NValt for example), so it would be great if this could be fixed. Thanks!

soulbarn

The developer apparently doesn't care enough about this to reply to several questions about this bug - either here or via Twitter. Love Editorial, but very disappointed. Maybe the issue can't be fixed..maybe it isn't a priority. That's fine, just let us know.

omz

Unfortunately, I haven't been able to reproduce this issue here. It works fine for me, and it's kind of difficult to guess why it may not work for some people. I'll look into it, but I'm not sure if/when I can actually find a fix.

Does it change anything if you select "Reset sync" in the "Advanced" settings?

ash

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.