Announcement

Collapse
No announcement yet.

F2FS Is The Latest Linux File-System With Patches For Case-Insensitive Support

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by starshipeleven View Post
    "meme filesystems", lol dude, if I wanted to let third parties dictate arbitrarily what I can or cannot use I would still be on Windows.
    Mega does the same. on KDE anyway. They have a full GUI (and cli-capable) sync client for more or less every major distro, OpenSUSE and Arch included. I don't know about GNOME tray support (it probably does not work as GNOME has no tray anymore afaik)
    Damn son where'd you find this

    Originally posted by starshipeleven View Post
    Mega also allows you to mirror arbitrary folders to arbitrary folders in your cloud storage, which is what I use to keep the bin folder where I keep all my helper scripts synced between my PCs.
    I just have all of mine in my Dropbox folder. :B

    Originally posted by starshipeleven View Post
    They also provide a blacklist so I can blacklist file names/types I don't want it to sync by wildcards.

    They also provide integration plugins for dolphin, Nemo, Nautilus and Thunar so you can see the icons of sync status on your files (similar to what Dropbox does on Windows), and also get a referral link to a specific file by rightclicking.
    Anything threatening the sublime simplicity of "a sync folder I put stuff in" is worrisome, but syncing arbitrary files/dirs is a plus! : 0

    I assume it's megasync on the AUR: https://aur.archlinux.org/packages/megasync

    Perchance, can you access the client through the Start Menu or some such similar contrivance? You can only get at Dropbox's settings through the tray icon's context menu or deal with the CLI, which is what makes it such a pain on GNOME; you can't just Meta Key>"Dropbox">Enter, and pull up the client window.

    Some reviews say Dropbox is faster: https://www.cloudwards.net/mega-vs-dropbox/

    Dropbox also uses S3 servers, which feels more robust. On the other side, I remember Kim's mansion being raided. I don't know. :s

    Mega seems better on security; they sell the "we can't see into your files either" angle, which is nice. But the way I use Dropbox is that I sync a VeraCrypt volume which I unlock at boot. It's more painful, but I don't have to take anyone's word, you know?
    Last edited by josh_walrath; 07-20-2019, 12:44 AM.

    Comment


    • #32
      Originally posted by starshipeleven View Post
      It's not exactly new feature, it's there since forever.
      Set all users in the same "users" or "family" or whatever group, and then setting the SGID would have any newly creatded files inherit the permissions of the parent folder they are in.
      https://linuxconfig.org/how-to-use-s...the-setgid-bit
      When used on a directory, instead, the setgid bit alters the standard behavior so that the group of the files created inside said directory, will not be that of the user who created them, but that of the parent directory itself. This is often used to ease the sharing of files (files will be modifiable by all the users that are part of said group). Just like the setuid, the setgid bit can easily be spotted (in this case on a test directory):

      KDE has that in the file/folder property popup, Permissions -> Advanced Permission button. It looks similar to Windows's advanced permissions. And had it for a long while too.

      I'm not aware about any issues caused by setting the SGID bit (and I used it for a long while in a server environment), and as I said above, it's not harder than doing it on windows if you are using a decent DE that does provide a GUI for it.

      Could you say what were your issues?
      (cc cybertraveler ) You need an ACL to override the umask and give default g+rwX permissions to the group, with a variant of:

      Code:
      setfacl -d -m u::rwx,g::rwx,o::r-x /your/sharedfolder/
      It isn't bulletproof, though (a user can manually remove the group permission, maybe there's an ACL to avoid that, but I don't know better). And it doesn't really help with removable media, or network shares where uid/gid mapping is random.

      Comment


      • #33
        [email protected] liking my post reminded me of this thread, and I was meaning to report in!

        Originally posted by starshipeleven View Post
        "meme filesystems", lol dude, if I wanted to let third parties dictate arbitrarily what I can or cannot use I would still be on Windows.

        A cloud sync application should not dictate what filesystem I'm using when all it does is set up a daemon that asks the kernel to notify it of modified files, and ask the kernel to read and write stuff. The underlying filesystem is completely irrelevant to it, any claims that they are "supporting" a filesystem is arrogant bullshit. Dropbox isn't using any filesystem-specific feature, they have exactly 0 tickets because of filesystem issues (also because there is no way to send them tickets, but I digress).

        I can understand throwing warnings if you use shit filesystems like FAT32 (like Mega does, and it does explain what issues it has when running on FAT32, but it is still just a warning).
        Restricting supported filesystems to one per OS does not make sense, it just sets a stupid precedent, what's next, deciding that their shit sync application only works with specific kernel versions (for no reason at all, again)?

        Sorry but that breaks the trust chain. I'm not trusting power-tripping idiots with keeping my data available, and a service running.

        The moment I got the popup saying "unsupported filesystem" I started looking for alternatives.

        How in the fuck can you claim that "dropbox is better" if you also admit that you don't know Mega.

        Mega does the same. on KDE anyway. They have a full GUI (and cli-capable) sync client for more or less every major distro, OpenSUSE and Arch included. I don't know about GNOME tray support (it probably does not work as GNOME has no tray anymore afaik)

        Mega also allows you to mirror arbitrary folders to arbitrary folders in your cloud storage, which is what I use to keep the bin folder where I keep all my helper scripts synced between my PCs.

        They also provide a blacklist so I can blacklist file names/types I don't want it to sync by wildcards.

        They also provide integration plugins for dolphin, Nemo, Nautilus and Thunar so you can see the icons of sync status on your files (similar to what Dropbox does on Windows), and also get a referral link to a specific file by rightclicking.

        It's Mega, and it's not "close", it's better.
        I've tried Mega, and it's not as good as Dropbox. :C

        Pros:
        - Accept Bitcoin
        - Flexible dirs
        - Fancy encryption
        - Can be opened from the launcher, which means it works on Gnome

        Cons:
        - VERY slow compared to Dropbox
        - Can't edit the same file on two comps simultaneously (I often do this because I forget to close files on my desktop, and there's something magical about watching the edits sync)
        - Uses modification times, no indexing for changes, to decide whether to reupload the whole file (is this why it's so much slower, on top of crypto?)
        - Phone camera uploads simply don't work (common issue, it seems)

        If you work with encrypted volumes (which I like to since I don't have to trust any cloud provider that way), you're looking at a 14 hour upload time vs. Dropbox's, what, 1 and a half? I easily make changes to my volume in that time, so I'd be in some permanent upload loop!

        Dropbox's clientside indexing is CPU intensive, which can be annoying, but it means that it uploads large files faster and (I assume) won't do things like undo reversions in git repos (though, technically, you're not supposed to cloud-sync any git repos... shh!).

        And, for a regular workflow, I guess it'd be fine if camera uploads worked, which is a hugely convenient feature. Poor Mega. I hope they do better. Haven't tried pCloud yet, but they also support Bitcoin!

        Also, as for Dropbox's rationale for selective FS support, have a look here: https://danluu.com/deconstruct-files/
        Last edited by josh_walrath; 08-12-2019, 10:00 AM.

        Comment


        • #34
          Originally posted by josh_walrath View Post
          Can't edit the same file on two comps simultaneously (I often do this because I forget to close files on my desktop, and there's something magical about watching the edits sync)
          This is a bad idea on Dropbox too, editing files from both PCs means it will create a copy called "<name-of-pc> different copy of <original file name>" or something like that.

          Sometimes Dropbox created dozens of such files because it saw some inconsistency (on Windows) and it was a fun times to find out what was newer and what was older.

          Uses modification times, no indexing for changes, to decide whether to reupload the whole file (is this why it's so much slower, on top of crypto?)
          Yes IF it's uploading the whole file instead of a diff, AND you are using large encrypted volumes instead of a bunch of small files.

          For example, while uploading only a few kb of a 100kb document is faster, it's still very fast. If your 100k document is in a multiGB volume, then yes it becomes slow as fuck.

          I don't usually edit huge multiMB files, it's mostly an archive I upload or download.

          The point to keep in mind is that most people won't be using encrypted volumes anyway, especially if one of the selling points of your Cloud service is its own encryption.

          - Phone camera uploads simply don't work (common issue, it seems)
          It depends from how strict is your Android with permissions and background processes ("battery optimization" settings), on my LineageOS phone and on my Huawei work phone with stock firmware it worked as long as the application was allowed to run in the background.

          Still, I'm not using their client anymore but an app called Autosync for Mega https://play.google.com/store/apps/d...async&hl=en_US which is basically the Mega version of the Dropsync app I was also using before, from the same developer.

          That app is a full sync client and allows me to keep stuff also on my phone's sdcard, so I can access my files without network connection too.

          If you work with encrypted volumes (which I like to since I don't have to trust any cloud provider that way), you're looking at a 14 hour upload time vs. Dropbox's, what, 1 and a half? I easily make changes to my volume in that time, so I'd be in some permanent upload loop!
          Hm, so that's why it has to choose which filesystems it supports.

          I'm not storing sensitive stuff in the cloud, so I never noticed, or even needed this capability. I keep files as files. Most people keeps files as files.

          Also this wasn't stated as the reason for dropping other filesystem support anywhere.

          Dropbox's clientside indexing is CPU intensive, which can be annoying, but it means that it uploads large files faster and (I assume) won't do things like undo reversions in git repos (though, technically, you're not supposed to cloud-sync any git repos... shh!).
          It uplades EDITS to large files faster, and it can mess up files if the underlying filesystem is not in sync with its own transaction log. I personally don't think this is a great idea.
          Syncthing (the opensource cloud application to make your own cloud) does diff syncs too and I would trust it over whatever shit Dropbox is pulling https://github.com/syncthing/syncthing/issues/107

          A simpler "upload whole files" approach does not carry risks of screwing with anything, as all filesystems will have that attribute and will more or less be truthful about it.

          Also, as for Dropbox's rationale for selective FS support, have a look here: https://danluu.com/deconstruct-files/
          This is a guy talking about working with filesystems, not a Dropbox official statement.

          While it's a good and sound reason, it's not "Dropbox's rationale". They never said why they switched, or why should people care.

          Also can I say that Dropbox was working fine with Btrfs on OpenSUSE Tumbleweed, and the FS I was getting glitches on was NTFS on (multiple machines running) Windows?

          Haven't tried pCloud yet, but they also support Bitcoin!
          Use Monero, as that's actually using an encrypted transaction log only you and the other party can see. Bitcoin stores that info in cleartext, anyone can track transactions of your account.

          Comment


          • #35
            Originally posted by starshipeleven View Post
            This is a bad idea on Dropbox too, editing files from both PCs means it will create a copy called "<name-of-pc> different copy of <original file name>" or something like that.

            Sometimes Dropbox created dozens of such files because it saw some inconsistency (on Windows) and it was a fun times to find out what was newer and what was older.
            Note: I've been using Dropbox on Linux for about two years.

            FWIW, I've only ever had this happen on Windows <--> Linux use, but I've used Windows so rarely lately that the clock is consistently wrong when I boot in, and I assumed that might've had to do with it. Not sure though.

            Otherwise, I've never had this happen between Linux instances.

            Originally posted by starshipeleven View Post
            I'm not storing sensitive stuff in the cloud, so I never noticed, or even needed this capability. I keep files as files.
            My "sensitive stuff" here is "important data that doesn't take a lot of space", and it's the stuff I'd miss the most if my entire computer exploded! : p So, as far as what I want backed up to a cloud, it's first on the list. But, of course, if you'd rather no one be able to see that data...

            Enter encrypted volumes!

            Using "files as files" over the cloud for this stuff seems like early Facebook, privacy-is-dead naivete. The alternative would be to have the stuff on local disks and have an automated backup (zip up the stuff -> delete old archive from cloud -> add new archive to cloud). The disadvantage there is that, on two machines, you have to unzip the archive to local dirs and replicate the automated backup there. With an archive you work inside of, just wait for the sync and you're good to go (or, at worst, you have two conflicted copies to pick between)!

            Originally posted by starshipeleven View Post
            It uplades EDITS to large files faster, and it can mess up files if the underlying filesystem is not in sync with its own transaction log. I personally don't think this is a great idea.
            . . .
            A simpler "upload whole files" approach does not carry risks of screwing with anything, as all filesystems will have that attribute and will more or less be truthful about it.
            . . .
            Also can I say that Dropbox was working fine with Btrfs on OpenSUSE Tumbleweed, and the FS I was getting glitches on was NTFS on (multiple machines running) Windows?
            Only if I can say that I've never had file corruption with Dropbox. c:

            Originally posted by starshipeleven View Post
            Use Monero, as that's actually using an encrypted transaction log only you and the other party can see. Bitcoin stores that info in cleartext, anyone can track transactions of your account.
            But nothing takes Monero. :c

            But yeah. It's the same rationale behind a VPN though: technically, "anyone" (of sufficient means) can track and correlate my activity through one, but I still use one because I'm betting Mega won't launch an intense investigation to figure out what my real IP is (e.g., visit my VPN provider, hold them at gunpoint until they hand over the logs they swore they don't keep or something).

            I also bet they won't do that with my Bitcoins.

            In the 99% of cases where my bet was right, I gained privacy that I would have lost if I engaged them with my real IP and/or regular financial technology. 👻 Success win

            Comment

            Working...
            X