@TonyLim@DTLow Thanks for your replies. TMI warning: “since you asked…”
the following point of view (POV) is based on this lay person’s experience. I remain open to other POVs:
Tony, iDrive is having problems (generating errors that create a failure status rather than success when backup is complete) with DT files. 1) the file names are two long because…
DTLow, it appears iDrive doesn’t recognize DT’s package and just copy the entire package as a single file, but rather copies each DT item separately. Doing so creates very long file names, hence the errors.
Having long experience with computers in general and the MacOS environment vs. Windows, etc., I find such little signals, if ignored lead to massive pain in the -ass! ha-ha, but not totally all ha-ha…
So, as a none techie, I like my tech tools to provide work for me, rather than the other way. Having a no-muss, no-fuss relationship—known in techie world as “bullet proof”—leaves me open to do other stuff.
I thought DT store files in various directory as individual files. Not packages. Or could you elaborate what do you mean by “packages”.
I had file names too long problem some times. This is usually because I copy clipboard to Markdown files without giving it a proper file name. As such, the Markdown file will take the first sentence as the file name. This resulted file names too long. This can be easily fixed when I give the Markdown file a proper name.
I check with iDrive support the max file name (path+filename) is 256 characters, which is acceptable to me.
And please remember, I’m a regular person using DT to run a business, not a coding person.
I mentioned packages due the reference found in my backup research here in the DT forum.
@TonyLim Your experience is similar to mind. What bothers me is iDrive keeps finding new files with too many characters each time it backs up.
This means, I’m finding myself going back and correcting new files after every backup. This means I’m spending way too much time with yet another technology tool that was suppose to work for me. But yet, here I am working for it!
What ever value I thought I was getting with the iDrive choice it is not gone.
At this point, I’m looking for what is known in the programing space as a “bullet proof” solutions. In this layman’s terms, a cloud backup solution that I can set once, and it works for me—so I can get on with my life…
What you are referring to as “packages” are presumably the databases; the database files contain a number of folders and - amongst other things - each one the items you see in DEVONthink, in its original format, using the file name you have provided for that item. As such, a database is not one larger file containing lots of data, but rather a wrapper around many many files.
Clever people of the forum: might the problem of long file paths be solved by using encrypted databases (i.e. sparseimages)? So what I’m saying is, is backup software going to treat a sparseimage as one file, or will it still be paths and names of the same length, just scrambled? (My understanding is that a sparseimage will consist of data chunks; making it possible to provide incremental backup, but effectively otherwise masking the contents such as paths etc.; but I actually lack knowledge in this area).
FWIW: I also use Arq (non premium); I’ve not had trouble with any long path names.
Certainly; but that depends on how the data is stored there (so a chunk of encrypted data which encodes a picture of a sunset at the end of a very long file path and name would be no problem, as opposed to that same data copied 1:1 with its path; the same must be true for the backup software itself: software which literally copies presumably runs into the problem, whilst software which stores backups in its own proprietary format may well not).
I’m assuming Arq uses proprietary containers of some ilk, and will not run into problems. Caution: I have not researched that.
I use Carbon Copy Cloner, Chronosync, Backblaze, and TimeMachine to drive backups to numerous places and have not noticed issues. i occasionally do test restores to confirm that conclusion. but of course maybe i am a fool. probably.
That strikes me as unlikely… I just don’t think the issue is wide spread; I assume most software mitigates; many locations certainly allow more than 256 characters (OD 400, macOS 1024, I believe); most file names just aren’t that long. Well that’s my explanation, anyway
