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

49254Re: VIM and NTFS streams

Expand Messages
  • Matt Wozniski
    Feb 4, 2008
    • 0 Attachment
      On Feb 4, 2008 4:29 PM, krischik wrote:
      > On 4 Feb., 21:10, "Matt Wozniski" wrote:
      > >
      > > While this would be nice, it would require support code from every
      > > application you have. It may only be 6 lines, but 6 lines * 5000
      > > binaries is much more code than is in vim for line ending detection.
      > But the other 5000 applications need detection as well. I did mention
      > webserver and browser getting detection wrong. konquror/nautilus/
      > explorer needs detection and far more complex then vim. And sure OS/2
      > needed detection. But there you could always overwrite faulty detected
      > value by manualy correcting the EA's.

      I'm not sure that most other apps do need detection. wget, for
      instance, doesn't have to care what line endings the data it saves
      has. But, for what you want, it would have to detect and save it,
      even though it doesn't use it. Shell redirection has no idea what's
      going through it, so it has no way to possibly say what Content-type
      it is... or dd... or tar extracting files that were created on a
      filesystem that didn't track extended attributes...

      > > After all, vim can't use this information unless something put it
      > > there, which requires that everything that can create a file - from
      > > touch to wget to shell redirection - needs to be able to put that
      > > attribute into the file. And, AFAIK, there's no way for those wget or
      > > shell redirection to even know what type of line ending the data that
      > > they wrote out had. Which means they'd need to detect it.
      > Just one example: The OS/2 version of ZIP would pack extended
      > attributes. Once it catches on then more application will support it.
      > But I know that this won't happen. We went down the "worse is better"
      > way for far to long.

      The issue isn't waiting for it to catch on, it's that until it's
      universally available it only increases the amount of code and
      maintenance burden. And, there's no way that it would ever be
      universally available for things like line endings style, because most
      applications just don't know or need to care, so have no reason to set
      that attribute. Things like marking the content encoding might be
      more useful, but still, not good to work with... If, for example, you
      had a file "test.txt" encoded in UTF-16 and with extended attributes
      marking it as such, and your locale is set to use UTF-8, what would
      you expect the result of "cp test.txt test2.txt" to be? What about
      "cat text.txt >text2.txt"? If you expect those two commands to have
      the same effect, I don't see how it can be done without changes to cp
      (mark attrs on dest), cat (mark attrs on stdout), and the kernel
      itself (allow extended attributes on streams).

      > > Which
      > > would require that just about every program out there that is
      > > transcribing a data stream from one spot to another, rather than
      > > authoring it itself, would need to duplicate the sort of EOL detection
      > > code in vim in itself. And vim would still need to continue
      > > supporting the old way since it's designed to run on filesystems that
      > > still don't support extended attributes - or it would need to come up
      > > with a way to fake extended attributes on those FS types. No one is
      > > saying that extended attributes can't do useful things - just that
      > > without being in any way standardized, it's unreasonable to expect
      > > that any attributes will ever be set by anyone but you.
      > Ahh, indeed, there is the problem and the reason why computing has not
      > advanced as much in the last 15 years as one would have expected
      > seeing the 15 years before: Backward compatibilty has hobbled us.

      The problem with this idea isn't the limitations inherent in backwards
      compatibility - if it were worthwhile to do, it's no problem to have
      code that uses attributes if possible and the old, backwards
      compatible method if not. The problem is that creating this standard
      and tying it properly into a POSIX OS would require a lot of low-level
      changes. If we can agree on the requirements - that there must be
      some number of predefined attributes that are set on every regular
      file (and what about special files?), that the operating system must
      handle initializing these attributes correctly when a file is created,
      that streams would also need to have attributes, and that copying,
      extracting, and in general "moving around" data will "just work", can
      you see how difficult this would be to implement? To fully implement
      this, the very least that's required is an operating system that only
      supports filesystems that have some way of storing extended
      attributes, a kernel that's able to initialize each of those
      attributes on every file created, a shell that knows how to get/set
      these attributes (and which it needs to set), and a copy of the
      coreutils that are aware of the changes (so that "cp file1 file2"
      creates file2 with the attrs of file1, not the defaults), at the very
      least? And that work is just the baseline - the point where other
      software can start counting on a base set of attributes that will
      always exist, and trusting that they're correct. On a quick glance, I
      see absolutely no way to do this properly without support from the OS.


      You received this message from the "vim_dev" maillist.
      For more information, visit http://www.vim.org/maillist.php
    • Show all 25 messages in this topic