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

49261Re: VIM and NTFS streams

Expand Messages
  • krischik
    Feb 5 2:07 AM
    • 0 Attachment
      On 4 Feb., 23:09, "Matt Wozniski" <m...@...> wrote:
      > 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.

      No, a EA aware wget would request the EA's already attached to the
      file from an EA aware ftp server - the same way it request file
      permissions today when used with "--preserve-permissions".

      > 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...

      That's true.

      > or tar extracting files that were created on a
      > filesystem that didn't track extended attributes...

      Well, you might like to ask the authors - xattr and acl support has
      been added to tar last year:

      http://www.redhatmagazine.com/2007/07/02/tips-from-an-rhce-tar-vs-star-the-battle-of-xattrs/

      > 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.

      You are proving my point: backward compatibility has hobbled software
      development.

      > 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?

      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.

      > 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).

      I do not expect that cat and cp behave the same. For the simple reason
      that they never have behaved the same: cp has options like "--
      preserve" and "--archive" - cat has not. Even today using cat to copy
      a file will mean that you loose the all the meta informations
      attached.

      > a shell that knows how to get/set
      > these attributes (and which it needs to set),

      Done: see setfattr and getfattr.

      > 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),

      Done: GNU cp will do that if --archive is used.

      > On a quick glance, I
      > see absolutely no way to do this properly without support from the OS.

      While I countered most of your arguments - you are absolutely right
      here. Only I have once used an operating system (OS/2) which did
      exactly that - hence my frustration.

      Martin
      --~--~---------~--~----~------------~-------~--~----~
      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