Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ending support for Dropbox syncing to drives with certain uncommon file systems

dropboxforum.com

Post reply on HN
Print view View original

381–390 of 429 posts

Re: Ending support for Dropbox syncing to drives with certain uncommon file systems

#381

Post by user5994461 »

JosephEJones wrote: post #89
Covzire wrote: post #27

Earlier quoted context omitted.

Does ZFS gaining steam on Linux in recent years have anything to do with the state of btrfs?

Does it really gain steam? Last time I checked the CDDL license incompatibility with GPL made it impossible to ship ZFS with Linux, and as such, distros have separate packages not maintained by the core team (I'm thinking of Arch right now). For the record I would be very glad if I could seamlessy use ZFS, but from my perspective it looks like a lot of work that can break in unexpected places.

ZFS is owned by Oracle now. It's more or less suicidal to embed it into any Linux distribution.

Re: Ending support for Dropbox syncing to drives with certain uncommon file systems

#382

Post by user5994461 »

ape4 wrote: post #218
blattimwind wrote: post #120

Earlier quoted context omitted.

extN xattrs are fairly limited, because iirc all xattrs of a given inode must be stored in the same block. I don't think XFS has any serious limitations (count/size) for them, but the Linux kernel itself limits the size to 64K.

You are correct. "man 5 attr" says: In the current ext2, ext3, and ext4 filesystem implementations, the total bytes used by the names and values of all of a file's extended attributes must fit in a single filesystem block (1024, 2048 or 4096 bytes, depending on the block size specified when the filesystem was created).

I would assume the block size is at least 4k for anything created in this era.

Re: Ending support for Dropbox syncing to drives with certain uncommon file systems

#383

Post by paulie_a »

lgunsch wrote: post #294
paulie_a wrote: post #264

Earlier quoted context omitted.

I would never attempt to use btrfs again in any environment. But if it is used, I hope the person has extremely strong backup policies in place for when it eventually crashes.

I've used it for the past 4 years as my primary development machine. Never once had an issue. However, I used Arch Linux, which always has newer kernels. I know there have been some bugs on other distros which run older kernels.

I ran it for quite a while, 4 terabytes lost specifically due to btrfs, I will never trust it again.

I've heard several admins flat out scoff at the idea of using it.

Make sure you have backups with a reliable fs.

Re: Ending support for Dropbox syncing to drives with certain uncommon file systems

#384

Post by ahnick »

Jedd wrote: post #378
ahnick wrote: post #359

Earlier quoted context omitted.

You use the tool as it is intended. With Keybase if you are opening and working directly from the Keybase folder that is mounted then you are using it wrong, so your scenario wouldn't happen if you are using Keybase correctly. The point I was trying to make is that for many people being able to copy back and forth between a local folder and a mounted directory is no different than what they do everyday at work with n…

> You use the tool as it is intended. With Keybase if you are opening and working directly from the Keybase folder that is mounted then you are using it wrong, so your scenario wouldn't happen if you are using Keybase correctly. You may be misunderstanding intent. Consider https://keybase.io/blog/encrypted-git-for-everyone

I don't think so. The encrypted git functionality in Keybase operates differently from kbfs. AFAIK the encrypted git ability just functions as a git remote helper that doesn't use the local kbfs mount on your system, so you wouldn't run into the same situation as say a file you are copying to your private keybase folder.

Also, to be clear, you could use the mounted files directly, but you just have to be aware that if you lose connectivity you may run into issues. If I was traveling somewhere and I'd like to work on a document in transit then I would recommend copying that to another folder on your local machine first.

Re: Ending support for Dropbox syncing to drives with certain uncommon file systems

#385

Post by exikyut »

Zak wrote: post #358
exikyut wrote: post #243

Earlier quoted context omitted.

What would "everyone else" do with Git? It's a Rube Goldberg solution implementing a highly specific set of ways to do file versioning. Most cloud storage providers offer rudimentary versioning; are you referring to the idea of promoting commits to being first-class? It would need to be baked into Word, Excel and similar, and those tools already have builtin version tracking, as horrible(?) as it is, so... :/

People I know who definitely have this problem tend to work in creative fields - especially musicians and (digital) visual artists. They almost universally have a bunch of files with names like project_final2_revised_reallyfinal3_with_edits_from_sally.psd. Of course, a solution that works well with all the different binary file formats people in those fields use wouldn't be easy.

Ah, that. Yes, absolutely I'd love for a solution that fixes that.

It would definitely need to work with large files though, which categorically precludes Git.

The first point, I think, would be building a delta engine with case-specific code for the most common ubiquitous file formats, like docx, xlsx, psd, etc. Of course it wouldn't be able to be perfect with everything but it would certainly be better than eg just recompressing each version or something equally naive.

The UX would be the next major hurdle. Time Machine is a good example of the kind of simplicity that would be needed, but it would need to be a have a bit more surface area to be applicable and useful to all scenarios.

One other feature that comes to mind, which would be incredibly difficult to get right but probably critical, would be useful version diffing. I think keeping this simple and just building something that can do $anything->SVG (with maybe cheats where bunches of the SVG is mostly just a bitmap in certain cases) and then doing something fast on the SVG (and/or its bitmap contents...) would probably be the most viable target.

Re: Ending support for Dropbox syncing to drives with certain uncommon file systems

#386

Post by ahnick »

jkaplowitz wrote: post #365
ahnick wrote: post #343

Earlier quoted context omitted.

Really? If you lose access to your dotfiles and OneNote notebooks for 5 or 10 minutes (that would be one long tunnel) that's completely unacceptable? This also sounds like a daily commute that could have easily been planned around if that time is really that important. Besides, when I work with Keybase I copy the files to my machine ahead of time to a local directory, so I likely would never notice such a drop in con…

Airplanes are a common case where people have long stretches without connectivity, either due to not paying for wifi or any if the other reasons it might be unavailable or unusable. Being on a NYC subway train is an even more interesting case, because depending on the precise client setup there's often intermittent or bad connectivity but rarely a good sustained connection between stations. As in most of the world, s…

Agreed, but these are planned events where you won't have connectivity, so you can copy the files to a local folder prior to the trip. I recognize that might not be as convenient as having the system perform a push to your machine to sync it. I think in those cases I'd probably just run rsync against the keybase folder.

Re: Ending support for Dropbox syncing to drives with certain uncommon file systems

#387

Post by anotherevan »

cesarb wrote: post #168
jonknee wrote: post #129

Earlier quoted context omitted.

I guess you could say it runs of everything unless you use one of the two most popular operating systems in the world: Android and iOS.

There's syncthing for Android: https://github.com/syncthing/syncthing-android

Only recently started playing with SyncThing (about the time SpiderOak's warrant canary expired).

To my mind, the Android app leaves a bit to be desired. Usually you don't want your phone to hold local copies of everything in the shared folder(s) as it is usually space constrained. You want to be able to view and pull files down as desired (possibly with the option to flag individual files to always be cached locally).

Re: Ending support for Dropbox syncing to drives with certain uncommon file systems

#388

Post by smittywerben »

user5994461 wrote: post #381
JosephEJones wrote: post #89

Earlier quoted context omitted.

Does it really gain steam? Last time I checked the CDDL license incompatibility with GPL made it impossible to ship ZFS with Linux, and as such, distros have separate packages not maintained by the core team (I'm thinking of Arch right now). For the record I would be very glad if I could seamlessy use ZFS, but from my perspective it looks like a lot of work that can break in unexpected places.

ZFS is owned by Oracle now. It's more or less suicidal to embed it into any Linux distribution.

This made me laugh. Maybe I'm missing something; I don't understand the downvotes.

Re: Ending support for Dropbox syncing to drives with certain uncommon file systems

#389

Post by pmorici »

thomasfedb wrote: post #10

The kicker is in the couching - dropping support for "uncommon filesystems" - of which their definition includes the default filesystem used by the most popular distro. Just dumb or wilfully ignorant?

I was under the impression that xfs was the default file system on recent versions of Redhat / Centos that's got to be a large share of the corporate Linux market.

Re: Ending support for Dropbox syncing to drives with certain uncommon file systems

#390

Post by rahimnathwani »

eloff wrote: post #214
rcarmo wrote: post #39

Earlier quoted context omitted.

Home directory encryption via ecryptfs is now the default in most Ubuntu variants, and it would be insane not to attempt to support it. That said, given that my Dropbox subscription just renewed (and that Linux is pretty much the only reason I'm still using it, since there is no OneDrive client I can rely on), I am really sad this seems to be a future direction for Dropbox.

I get a terabyte free with onedrive, because of the office subscription. I wish I had a good way to utilize it on Linux.

rclone mount
Post reply on HN