That doesn't really make a lot of sense, though. Reading a file that's not actually on disk doesn't download it permanently. If I have zero of 10TB worth of files stored locally on my 1TB device, read them all serially, and measure my disk usage, there's no reason the disk should be full, or at least it should be cache that can be easily freed. The only time this is potentially a problem is if one of the files exceeds the total disk space available.

Hell, if I open a directory of photos and my OS tries to pull exif data for each one, it would be wild if that caused those files to be fully downloaded and consume disk space.

▲

jrmg 6 hours ago | parent | next [-]

Right, but even if that’s working it breaks the user experience of services like this that ‘files I used recently are on my device’.

After a backup, you’d go out to a coffee shop or on a plane only to find that the files in the synced folder you used yesterday, and expected to still be there, were not - but photos from ten years ago were available!

▲

wtallis 4 hours ago | parent | next [-]

That shouldn't be seen as Backblaze's problem. It's Dropbox's problem that they made their product too complicated for users to reason about. The original Dropbox concept was "a folder that syncs" and there would be nothing problematic about Backblaze or anything else trying to back it up like any other folder.

Today's Dropbox is a network file system with inscrutable cache behavior that seeks to hide from the users the information about which files are actually present. That makes it impossible for normal users to correctly reason about its behavior, to have correct expectations for what will be available offline or what the side effects of opening a file will be, and Backblaze is stuck trying to cope with a situation where there is no right answer.

▲

realo 4 hours ago | parent [-]

If I backup a file, I need to read that file. The rest is in the management layer underneath that file.

Seems simple enough to do for Backblaze, no?

▲

wtallis 3 hours ago | parent [-]

Do you really want Backblaze to ignore all the side effects of scanning through the entire contents a badly-designed network filesystem?

▲

realo 2 hours ago | parent [-]

What I actually want is not a backup. That is just an artefact of the process.

What i want is restores. The ability to restore anything from ideally any point back in time.

How that is achieved is not my concern.

Obviously Backblaze does not achieve that, today.

	▲	wtallis an hour ago \| parent [-]
		> How that is achieved is not my concern. You're dodging the question. Wanting to ignore the side effects does not mean they won't affect you.

▲

NetMageSCW 6 hours ago | parent | prev [-]

There’s no reason to think that would happen - files you had from ten years ago would have been backed up ten years ago and would be skipped over today.

	▲	jrmg 6 hours ago \| parent [-]
		Good point (I’m assuming you’re right here and it trusts file metadata and doesn’t read files it’s already backed up?) It would still happen with the first backup - or first connection of the cloud drive - though, which isn’t a great post-setup new user experience. It probably drove complaints and cancellations. I feel like I’ve accidentally started defending the concept of not backing up these folders, which I didn’t really intend to. I’d also want these backed up. I’m just thinking out loud about the reasons the decision was made.

▲

bombcar 6 hours ago | parent | prev [-]

It's generally now handled decently well, but with three or four of these things it can make backups take annoying long as without "smarts" (which are not always present) it may force a download of the entire OneDrive/Box each time - even if it never crashes out.

	▲	bastawhiz 4 hours ago \| parent [-]
		> it may force a download of the entire OneDrive/Box each time - even if it never crashes out. I am not aware of any evidence supporting this.