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

The new Dropbox

blog.dropbox.com

Post reply on HN
Print view View original

571–580 of 590 posts

Re: The new Dropbox

#571

Post by jolmg »

mzs wrote: post #541
bigiain wrote: post #536

Earlier quoted context omitted.

"Please wait: backing up /dev/urandom - 0% of NaN" (To be fair, anyone who tries to backup /dev deserves whatever they get...)

$ echo /dev/urandom | cpio -o | xxd -a 1 block 00000000: 3037 3037 3037 3737 3737 3737 3030 3030 0707077777770000 00000010: 3031 3032 3036 3636 3030 3030 3030 3030 0102066600000000 00000020: 3030 3030 3030 3030 3031 3737 3737 3737 0000000001777777 00000030: 3133 3436 3430 3530 3035 3730 3030 3031 1346405005700001 00000040: 3530 3030 3030 3030 3030 3030 2f64 6576 500000000000/dev 00000050: 2f75 7261 6e64 6f6d 0030 373…

I chuckled at the "TRAILER!!!". I wonder what other file formats have silly things like this.

From `man 5 cpio`:

> The end of the archive is indicated by a special record with the pathname “TRAILER!!!”.

This makes me wonder if this means that the cpio format can't reliably be used for files with the path "TRAILER!!!". Why would the format even need a special record to indicate the end of the archive? Is there any reason why one wouldn't be able to rely on the end of the file to indicate the end of the archive?

Re: The new Dropbox

#572

Post by jolmg »

jolmg wrote: post #571
mzs wrote: post #541

Earlier quoted context omitted.

$ echo /dev/urandom | cpio -o | xxd -a 1 block 00000000: 3037 3037 3037 3737 3737 3737 3030 3030 0707077777770000 00000010: 3031 3032 3036 3636 3030 3030 3030 3030 0102066600000000 00000020: 3030 3030 3030 3030 3031 3737 3737 3737 0000000001777777 00000030: 3133 3436 3430 3530 3035 3730 3030 3031 1346405005700001 00000040: 3530 3030 3030 3030 3030 3030 2f64 6576 500000000000/dev 00000050: 2f75 7261 6e64 6f6d 0030 373…

I chuckled at the "TRAILER!!!". I wonder what other file formats have silly things like this. From `man 5 cpio`: > The end of the archive is indicated by a special record with the pathname “TRAILER!!!”. This makes me wonder if this means that the cpio format can't reliably be used for files with the path "TRAILER!!!". Why would the format even need a special record to indicate the end of the archive? Is there any rea…

Seems cpio really can't deal with "TRAILER!!!" files:

  $ cd $(mktemp -d)
  $ echo foo > 'TRAILER!!!'     
  $ echo bar > barfile
  $ echo 'TRAILER!!!' | cpio -o | xxd -a
  1 block
  00000000: c771 2a00 31cc a481 e803 e803 0100 0000  .q*.1...........
  00000010: 025d ef8c 0b00 0000 0400 5452 4149 4c45  .]........TRAILE
  00000020: 5221 2121 0000 666f 6f0a c771 0000 0000  R!!!..foo..q....
  00000030: 0000 0000 0000 0100 0000 0000 0000 0b00  ................
  00000040: 0000 0000 5452 4149 4c45 5221 2121 0000  ....TRAILER!!!..
  00000050: 0000 0000 0000 0000 0000 0000 0000 0000  ................
  *
  000001f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
  $ echo 'TRAILER!!!' | cpio -o | cpio -t
  1 block
  1 block
  $ echo barfile | cpio -o | cpio -t
  1 block
  barfile
  1 block
  $ echo barfile | cpio -o | cpio -i --to-stdout barfile 
  1 block
  bar
  1 block
  $ echo 'TRAILER!!!' | cpio -o | cpio -i --to-stdout 'TRAILER!!!'
  1 block
  1 block

Re: The new Dropbox

#573

Post by tonyedgecombe »

c256 wrote: post #453
agumonkey wrote: post #258

Earlier quoted context omitted.

dropbox, considering their size, is really in a position for a solid rewrite. ocaml ? http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-ret... nim ? rust ? go ?

DropBox is the Electron client of file sharing. They could make native apps that use native apis and get vastly better performance in time, power, cpu, and probably memory — but then they’d have to create and maintain a bunch of native apps. I know it’s common to hear HN comments like “they have the money/skill/opportunity to trade up to a better platform for more effort”, but everything I’ve seen says that it’s much…

It does bundle Chromium so it isn’t far off.

Re: The new Dropbox

#574

Post by mzs »

jolmg wrote: post #572
jolmg wrote: post #571

Earlier quoted context omitted.

I chuckled at the "TRAILER!!!". I wonder what other file formats have silly things like this. From `man 5 cpio`: > The end of the archive is indicated by a special record with the pathname “TRAILER!!!”. This makes me wonder if this means that the cpio format can't reliably be used for files with the path "TRAILER!!!". Why would the format even need a special record to indicate the end of the archive? Is there any rea…

Seems cpio really can't deal with "TRAILER!!!" files: $ cd $(mktemp -d) $ echo foo > 'TRAILER!!!' $ echo bar > barfile $ echo 'TRAILER!!!' | cpio -o | xxd -a 1 block 00000000: c771 2a00 31cc a481 e803 e803 0100 0000 .q*.1........... 00000010: 025d ef8c 0b00 0000 0400 5452 4149 4c45 .]........TRAILE 00000020: 5221 2121 0000 666f 6f0a c771 0000 0000 R!!!..foo..q.... 00000030: 0000 0000 0000 0100 0000 0000 0000 0b00 ...…

tar has two blocks of zeros at the end.

GNU tar uses entries where other tar implementations will overwrite previous files on extraction, AIX tar uses special four character names for binary blobs (plus xattrs as names, both after the affected entry), Solaris cpio uses another mode bit for sparse files, ACLs, and xattrs (I actually really like this, it extracts as a simple to parse text file[0] on other implementations), and most pax commands on Linux can't read/write PAX archive files.

FWIW I make use of TRAILER!!! to let me know in a pipeline that everything worked (imagine a command earlier in the pipe fails early and not every entry is processed but ends on a boundary), but here the two pages of zeros that tar uses makes more sense (about the only thing tar does better than cpio).

0: https://www.mail-archive.com/opensolaris-arc@mail.opensolari...

Re: The new Dropbox

#575

Post by flipcoder »

rossdavidh wrote: post #106

So, it appears that Dropbox is letting feature creep turn a perfectly good product which I would have paid for forever, into one I need to leave. What is the best alternative? Just looking for automatic syncing and backup, and the historical versions available from the server is nice also. Suggestions? Simpler is better.

I switched to MEGA. The desktop client MEGAsync is actually quite decent. Very similar to classic dropbox

Re: The new Dropbox

#577

Post by hdfbdtbcdg »

usaar333 wrote: post #423
hdfbdtbcdg wrote: post #418

Earlier quoted context omitted.

> windows XP (the most popular OS when Dropbox came out!). Symlinks actually worked in Dropbox when I used to use it in 2012...

Define "work"? Dropbox has never sync'd a symlink as a symlink - it follows then on the client machine and a copy is created on the server. (Source: worked there)

When did you work there?

Re: The new Dropbox

#578

Post by zerd »

jhurwitz wrote: post #454
eridius wrote: post #390

Earlier quoted context omitted.

They use Rust in the datacenter. The layer that actually writes bits to disk is written in Rust. I don't know why they haven't yet deployed a native desktop client that's a Rust core with a thin platform-native GUI wrapper.

Jamie Turner from Dropbox gave a talk at a Rust meetup in 2017: https://air.mozilla.org/rust-meetup-may-2017/ Edit: at 30:05 in that video, he briefly talks about a forthcoming (as of 2017) "full redesign + rewrite of Dropbox's 'sync engine' in Rust." He claims it will use 10x less memory, and be 50x faster on key operations.

The also mention it here https://news.ycombinator.com/item?id=14926851

strings /Applications/Dropbox.app/Contents/Frameworks/libdropbox_watchdog.dylib | grep -i rust shows some hits:

  __ZN14rustc_demangle8demangle17h2ad719809986c0fcE
  _rust_begin_unwind
  /Users/vagrant/client-dropbox-python/dropbox-virtual-env-3985da1e510f-mac-x86_64-10.14/rust/lib/rustlib/x86_64-apple-darwin/lib/libcompiler_builtins-f10e664516557f83.rlib(compiler_builtins-f10e664516557f83.compiler_builtins.7wkmozn8-cgu.0.rcgu.o)
  ___rust_probestack
  /Users/travis/.cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.5/src/probestack.rs
  ___rust_alloc
  ___rust_dealloc
  ___rust_realloc
  ___rust_alloc_zeroed
  /Users/vagrant/src/client/rust_vendor/hyper-0.10.13/src/buffer.rs
  /Users/vagrant/src/client/rust_vendor/serde_json-1.0.33/src/read.rs
  ...
Looks like they use it fairly lightly though.

Re: The new Dropbox

#579

Post by robyn92 »

dcx wrote: post #81
randlet wrote: post #51

Earlier quoted context omitted.

pCloud works well for me (support for all major platforms). Google drive has no Linux support which is a deal killer for me.

pCloud looks pretty good - I happen to be shopping around for a Dropbox replacement too. But just a heads-up, when I checked around online I found these [1] [2] [3] comments. It sounds like they have a tool that runs internally to detect piracy and it sometimes picks up false positives, which might cause your account to be deleted? [1] https://www.reddit.com/r/privacy/comments/am2xbn/pcloud_allo... [2] https://www.re…

I have contacted them and it seems they use hash file organization to look up for these blobs, and also it would be stupid not storing your porn on the zero-encrypted folder they have... If you want to keep your pirate files there it might be the same logic dunno :D

Re: The new Dropbox

#580

Post by aldanor »

agumonkey wrote: post #258
jwr wrote: post #208

Earlier quoted context omitted.

Seconded. I can't put too many files in Dropbox, and additionally it burns power even if files are changed outside. In general, it is a CPU catastrophe, a penalty I have to pay in order to use file synchronization. I really hope that a better competitor appears. Additionally, the software pesters me with annoying popups pushing me to upgrade.

dropbox, considering their size, is really in a position for a solid rewrite. ocaml ? http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-ret... nim ? rust ? go ?

It's particularly funny because they hired Guido (GVR) who is supposedly helping them migrate a million(s) lines of code py2->py3. Whereas a better solution in the long run would have probably been just rewriting the whole damn thing in Rust for all platforms.
Post reply on HN