Loading ...
Sorry, an error occurred while loading the content.

Re: VIM and NTFS streams

Expand Messages
  • krischik
    ... I never meant that - I was just countering the claim that named forks are useless. And I only used Vim as an example of where Vim would have been simpler
    Message 1 of 25 , Feb 5, 2008
    • 0 Attachment
      On 5 Feb., 00:12, Ben Schmidt <mail_ben_schm...@...> wrote:

      > And that sad story told, I do agree with the other posters who don't think this
      > has much use in Vim. I think to have some kind of consistency, probably an OS or
      > other fairly central component needs to lead the way, not a text editor.

      I never meant that - I was just countering the claim that "named
      forks" are useless. And I only used Vim as an example of where Vim
      would have been simpler to implement - on an operating system which
      properly supports "type attributes".

      Sad that everybody else only sees only hurdles and risks of change and
      not the chances and the risk of no-change.

      And yes: there is a rist of no-change!

      The risk of an ever more complex software world with ever more complex
      solutions which could be done much easier if one would have done it
      right from the beginning.

      And the risk of ever more exploits of those complex solutions.

      Martin
      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_dev" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • Tony Mechelynck
      krischik wrote: [...] ... [...] ... [...] Hmm... According to info cp (on my openSUSE 10.3 system), -a or --archive is equivalent to -dpPR, which means: -d
      Message 2 of 25 , Feb 5, 2008
      • 0 Attachment
        krischik wrote:
        [...]
        > I would use "cp --archive test.txt test2.txt" in which case the EA's
        > are copied as well. At least on SuSE Linux 9.2 onwards. And of course
        > the file would still be UTF-16 - after all it's "copy" not "convert".
        >
        > Without meaning offence: You should read up a little on the subject as
        > you knowledge is not up to date.
        [...]
        > Done: GNU cp will do that if --archive is used.
        [...]

        Hmm... According to "info cp" (on my openSUSE 10.3 system), -a or --archive is
        equivalent to -dpPR, which means:

        -d copy symlinks as symlinks and preserve hardlinks between sources in the copies
        -p preserve attributes. If not specifying which attributes, the default is:
        mode,ownership,timestamps (xattrs must be specified explicitly to be included)
        -P copy symlinks as symlinks (sic)
        -R copy directories recursively


        Best regards,
        Tony.
        --
        "She said, `I know you ... you cannot sing'. I said, `That's nothing,
        you should hear me play piano.'"
        -- Morrisey


        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_dev" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • krischik
        On 5 Feb., 11:37, Tony Mechelynck ... Well I did not read the manual but copied a file with xattr (Samba creates them at mass)
        Message 3 of 25 , Feb 5, 2008
        • 0 Attachment
          On 5 Feb., 11:37, Tony Mechelynck <antoine.mechely...@...>
          wrote:
          > krischik wrote:
          >
          > [...]> I would use "cp --archive test.txt test2.txt" in which case the EA's
          > > are copied as well. At least on SuSE Linux 9.2 onwards. And of course
          > > the file would still be UTF-16 - after all it's "copy" not "convert".
          >
          > > Without meaning offence: You should read up a little on the subject as
          > > you knowledge is not up to date.
          > [...]
          > > Done: GNU cp will do that if --archive is used.
          >
          > [...]
          >
          > Hmm... According to "info cp" (on my openSUSE 10.3 system), -a or --archive is
          > equivalent to -dpPR, which means:
          >
          > -d copy symlinks as symlinks and preserve hardlinks between sources in the copies
          > -p preserve attributes. If not specifying which attributes, the default is:
          > mode,ownership,timestamps (xattrs must be specified explicitly to be included)
          > -P copy symlinks as symlinks (sic)
          > -R copy directories recursively

          Well I did not read the manual but copied a file with xattr (Samba
          creates them at mass) and saw what happened. But that was on a fairly
          old SuSE 9.2. I check SuSE 10.3 when I am home.

          Martin


          --~--~---------~--~----~------------~-------~--~----~
          You received this message from the "vim_dev" maillist.
          For more information, visit http://www.vim.org/maillist.php
          -~----------~----~----~----~------~----~------~--~---
        • Paul LeoNerd Evans
          On Tue, 5 Feb 2008 02:25:26 -0800 (PST) ... I have to agree with krischik here. At University, I once got stuck in a problem with some of the other
          Message 4 of 25 , Feb 5, 2008
          • 0 Attachment
            On Tue, 5 Feb 2008 02:25:26 -0800 (PST)
            krischik <krischik@...> wrote:

            > Sad that everybody else only sees only hurdles and risks of change and
            > not the chances and the risk of no-change.
            >
            > And yes: there is a rist of no-change!

            I have to agree with krischik here. At University, I once got stuck in a
            problem with some of the other mathematicians, who were all of the
            opinion that "Yes, I'll have tea if you're having tea". Problem was,
            nobody actually had tea. It took one of the lawyers to stand up and say
            "Alright then, I'll have tea." Then all the mathmos jumped ship.

            An amusing story perhaps, but it proves the point. In all things like
            this, someone needs to jump first. Does it really matter who that is, as
            long as someone does?

            It's been a bone of contention of mine for years, the way modified keys
            work in terminals. Five years ago XTerm gained ways to express generic
            modified keys (e.g. Ctrl-Shift-Left). Only recently did any application,
            such as Vim, start to understand those. It's always been a "you jump,
            I'll jump" situation - why should the terminal send sequences nobody
            would understand, or why should any application look for sequences nobody
            would send? Someone has to go first.

            Back to the subject of EAs - someone already has gone first. The GNU
            fileutils already support EAs. As does tar. I also know that the lighttpd
            webserver uses them by default, only falling back on filename-based
            detection if the file doesn't have a "Content-Type" EA.

            It'd be lovely if Vim could set those for it.

            --
            Paul "LeoNerd" Evans

            leonerd@...
            ICQ# 4135350 | Registered Linux# 179460
            http://www.leonerd.org.uk/
          • krischik
            ... Funny as you say - on my research for my little rants here (yes I do research before I rant) I found out that Apache too uses EA s when to store and detect
            Message 5 of 25 , Feb 5, 2008
            • 0 Attachment
              On 5 Feb., 12:55, Paul LeoNerd Evans <leon...@...> wrote:

              > I also know that the lighttpd
              > webserver uses them by default, only falling back on filename-based
              > detection if the file doesn't have a "Content-Type" EA.

              Funny as you say - on my research for my little rants here (yes I do
              research before I rant) I found out that Apache too uses EA's when to
              store and detect file types.

              And then there is Samba which uses "user.DOSATTRIB" to store dos
              attributes.

              > It'd be lovely if Vim could set those for it.

              That would be a nice indeed. - Bram - are you still with us?

              Martin
              --~--~---------~--~----~------------~-------~--~----~
              You received this message from the "vim_dev" maillist.
              For more information, visit http://www.vim.org/maillist.php
              -~----------~----~----~----~------~----~------~--~---
            • Alexei Alexandrov
              ... Oh, thanks - this is a good learning for me. It s a shame I never heard of this before. ... Such attributes would be useful, yes. But it s backward
              Message 6 of 25 , Feb 5, 2008
              • 0 Attachment
                krischik wrote:
                >
                > Open a console and type "man 5 attr"? Or look here:
                >
                > http://linux.die.net/man/5/attr
                >
                >
                > No it has nothing to do with Linux. FreeBSD, Solaris and Mac OS X
                > support extended attributes as well. See:
                >
                > http://en.wikipedia.org/wiki/Extended_file_attributes
                >
                > Quote Wikipedia: "In Linux, the ext2, ext3, ext4, JFS, ReiserFS and
                > XFS filesystems support extended attributes (abbreviated xattr) if the
                > libattr feature is enabled in the kernel configuration. "

                Oh, thanks - this is a good learning for me. It's a shame I never heard
                of this before.

                >
                > On the other hand use of extended attributes could solve a problem
                > with 5 lines of code where solving the same problem without could cost
                > you 50. Determine file types, text file line endings and text file
                > encoding come to my mind here. Ask Bram how many line of code he
                > needed in Vim to determine these three informations. With consequent
                > use of xattribs it would have been 6 lines:
                >
                > [...]
                >
                > And best of all: you know before you open the file. AFAIK Bram need to
                > close and reopen files in unfortunate combinations.
                >

                Such attributes would be useful, yes. But it's backward compatibility
                that is the root of all evil and you also mentioned this in a sibling
                post. So I'm not sure these things will become popular unless there is a
                brand new OS appears which doesn't have to be compatible with anything
                and it wins the market.

                Also, the named attributes story doesn't have to do much with numbered
                NTFS data streams, does it? It might be similar but numbers are too far
                from string identifier convenience. Which brings me back to my original
                thought - the design and implementation of data streams in NTFS are useless.

                --
                Alexei Alexandrov


                --~--~---------~--~----~------------~-------~--~----~
                You received this message from the "vim_dev" maillist.
                For more information, visit http://www.vim.org/maillist.php
                -~----------~----~----~----~------~----~------~--~---
              • krischik
                On 5 Feb., 22:54, Alexei Alexandrov ... I fear you missed something - since NTFS v3.0 named forks are supported. They are called
                Message 7 of 25 , Feb 5, 2008
                • 0 Attachment
                  On 5 Feb., 22:54, Alexei Alexandrov <alexei.alexand...@...>
                  wrote:

                  > Also, the named attributes story doesn't have to do much with numbered
                  > NTFS data streams, does it?

                  I fear you missed something - since NTFS v3.0 named forks are
                  supported. They are called "Alternate data streams". See

                  http://en.wikipedia.org/wiki/NTFS#Features

                  Martin
                  --~--~---------~--~----~------------~-------~--~----~
                  You received this message from the "vim_dev" maillist.
                  For more information, visit http://www.vim.org/maillist.php
                  -~----------~----~----~----~------~----~------~--~---
                • Bram Moolenaar
                  ... Vim doesn t detect the situation that you are editing an info stream directly. ... The writebackup option matters too. ... Detecting the colon should be
                  Message 8 of 25 , Feb 6, 2008
                  • 0 Attachment
                    Alex Jakushev wrote:

                    > On 1/31/08, Bram Moolenaar <Bram@...> wrote:
                    > >
                    > > Try setting the 'backupcopy' option to "yes".
                    >
                    > This worked, but then it raises another question. Previous value
                    > of the 'backupcopy' option was auto, which means yes or no, which
                    > works best. Why didn't it choose yes, if no fails?

                    Vim doesn't detect the situation that you are editing an info stream
                    directly.

                    > Also, in my configuration, backup option is no. Theoretically, I should
                    > not bother with all this stuff at all? I use Vim7.1 last official release.

                    The 'writebackup' option matters too.

                    > > I thought Vim did copy the streams, but I suppose this doesn't work when
                    > > you edit one specific stream. If you want to look at it: function
                    > > copy_infostreams() in src/os_win32.c
                    >
                    > This may take a while for me to set up everything...
                    >
                    > But i have an idea that the problem is with file names.
                    > When you open some specific stream, vim considers the stream name as
                    > filename, and filename as subfolder. The stream name is separated from file
                    > name with a colon (c:\path\foo.txt:bar), and the same colon is used to
                    > separate drive letter. Maybe this causes some confusion?

                    Detecting the colon should be simple. When not using NTFS the file name
                    would be illegal. I'll add a todo item for this. But it would be nice
                    if someone can make a patch for it.

                    > Also, VIM converts dots in file name to underscores sometimes, when
                    > streams are specified.

                    I haven't seen this. Perhaps it's because the long file name is
                    converted to a 8.3 file name? Can you give a reproducable example?

                    > > NTFS streams are mostly restricted to MS-Windows applications, and
                    > > rarely used. I don't think it's a good idea to support them in Vim
                    > > directly.
                    >
                    > I understand it, but vim has specific windows functionality anyway.
                    > But of course it is easy for me to suggest this and that :)

                    I always put more effort in functionality that works everywhere. And to
                    keep programs portable rare features should be avoided, especially when
                    they don't add something essential for the end user. MS thinks
                    otherwise: They want programs to only run on MS-Windows. Portability
                    means they might lose customers. Some Linux developers also go in this
                    direction, they don't care about MS-Windows users. I care for everybody
                    :-).

                    --
                    The process for understanding customers primarily involves sitting around with
                    other marketing people and talking about what you would to if you were dumb
                    enough to be a customer.
                    (Scott Adams - The Dilbert principle)

                    /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                    /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                    \\\ download, build and distribute -- http://www.A-A-P.org ///
                    \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

                    --~--~---------~--~----~------------~-------~--~----~
                    You received this message from the "vim_dev" maillist.
                    For more information, visit http://www.vim.org/maillist.php
                    -~----------~----~----~----~------~----~------~--~---
                  • Alexei Alexandrov
                    ... Oops, yep, I have a lot of stuff to catch up with. -- Alexei Alexandrov --~--~---------~--~----~------------~-------~--~----~ You received this message
                    Message 9 of 25 , Feb 6, 2008
                    • 0 Attachment
                      krischik wrote:
                      >
                      > I fear you missed something - since NTFS v3.0 named forks are
                      > supported. They are called "Alternate data streams".
                      >

                      Oops, yep, I have a lot of stuff to catch up with.

                      --
                      Alexei Alexandrov


                      --~--~---------~--~----~------------~-------~--~----~
                      You received this message from the "vim_dev" maillist.
                      For more information, visit http://www.vim.org/maillist.php
                      -~----------~----~----~----~------~----~------~--~---
                    Your message has been successfully submitted and would be delivered to recipients shortly.