49261Re: VIM and NTFS streams
- Feb 5 2:07 AMOn 4 Feb., 23:09, "Matt Wozniski" <m...@...> wrote:
> On Feb 4, 2008 4:29 PM, krischik wrote:No, a EA aware wget would request the EA's already attached to the
> > 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.
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'sThat's true.
> 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 aWell, you might like to ask the authors - xattr and acl support has
> filesystem that didn't track extended attributes...
been added to tar last year:
> The issue isn't waiting for it to catch on, it's that until it'sYou are proving my point: backward compatibility has hobbled software
> universally available it only increases the amount of code and
> maintenance burden.
> Things like marking the content encoding might beI would use "cp --archive test.txt test2.txt" in which case the EA's
> 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?
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 aboutI do not expect that cat and cp behave the same. For the simple reason
> "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).
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
> a shell that knows how to get/setDone: see setfattr and getfattr.
> these attributes (and which it needs to set),
> and a copy of theDone: GNU cp will do that if --archive is used.
> coreutils that are aware of the changes (so that "cp file1 file2"
> creates file2 with the attrs of file1, not the defaults),
> On a quick glance, IWhile I countered most of your arguments - you are absolutely right
> see absolutely no way to do this properly without support from the OS.
here. Only I have once used an operating system (OS/2) which did
exactly that - hence my frustration.
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
- << Previous post in topic Next post in topic >>