At Sun, 19 Apr 2009 20:06:43 +0200 CentOS mailing list <centos@xxxxxxxxxx> wrote:
>
> Robert Heller a écrit :
> > At Sun, 19 Apr 2009 15:07:05 +0200 CentOS mailing list <centos@xxxxxxxxxx> wrote:
> >
> >> Robert Heller a écrit :
> >>> [snip]
> >>>
> >>> Linux does not care about file *names*.
> >> indeed Linux does not. but desktop managers do. That said, *.exe attacks
> >
> > Are you sure? I would think that *Linux*-based desktop managers would
> > do something 'smart' like use the results of file (specificly 'file -i
> > ..') rather than depend on the file name itself.
>
> I just tried: renaming a .mp3 to a .gif and double clicking. I get an
> error saying something like "bad gif file"...
I'd consider that a 'bug' with the desktop manager (if I were to use
such as thing -- I don't/won't).
>
> The problem with the "file type" is that users don't see it. when I
> click to open a file, I somewhat "trust" the extension. If I open
> foo.png, it's because I want top open an image, not to run latex or make.
Many naive users save their images or document as 'my image' and don't
explicitly add an extension. (Under MS-Windows the O/S or application
sticks an extension on and never displays it -- a really *bad* thing
that is commonly exploited by E-Mail virus writers ala foo.jpeg.exe.)
MacOS(X) lets users save any sort of file with any sort of name and
makes no attempt to add or enforce file name extension conventions.
Old school UNIX users add extensions mostly by convention and for
convience. Only compiler execs (eg gcc) and the like pay any attention
to the extensions most of the time.
>
> maybe the solution would be to check that the extension matches the file
> type and if not warn the user.
The *original* desktop manager / GUI O/S, MacOS, uses a special file
(finder info) to save the application code of the application (4 [text]
bytes, one long word) and the file 'type' (also 4 [text] bytes, one
long word) whenever a file was created. The 'finder info' was part of
the file system 'meta data'. The file 'name' (with or without any
'extension') was NEVER used to determine how to deal with the file. I
believe MacOSX still does something similar (I don't know if MacOSX uses
file system 'meta data' or if MacOSX uses the file utility (or something
like the file utility).
>
>
> > I know that since
> > MS-Windows lacks anything like the file command (as part of the native
> > O/S install), it uses the file extension as a 'type'.
> >
>
> While that was inherited from DOS, the fact that windows took the "it's
> all about clicking" way, they didn't have much choice. and it gets
> annoying anyway:
Not really inherited from DOS, since DOS (like CP/M) did not really do
anything *itself* with file extensions (other than having a directory
structure that stored file names as a pair of fixed-length text strings
(ala struct {char name[8]; char ext[3];}).
>
> - when I double click on a ".pl", do I want to run perl or do I want to
> edit the file?
Under the MacOS 'way' clicking on it would be to run perl. I believe
something like Apple-Click (or shift or ctrl)-click would pop up a menu
of possible applications to open with, based on the *type*, which would
include a text editor (since a perl script would be of type TEXT, with
an app code of something like PERL).
>
> - sometimes, when you remove an application (on windows xp), the system
> can no more find the "most appropriate" application (even if you have
> many apps that would be ok).
>
> - many applications have a tendency to "steal" a lot of extensions.
> under windows, I never let such an app to register any association!
>
> ...
>
> _______________________________________________
> CentOS mailing list
> CentOS@xxxxxxxxxx
> http://lists.centos.org/mailman/listinfo/centos
>
>
--
Robert Heller -- 978-544-6933
Deepwoods Software -- Download the Model Railroad System
http://www.deepsoft.com/ -- Binaries for Linux and MS-Windows
heller@xxxxxxxxxxxx -- http://www.deepsoft.com/ModelRailroadSystem/
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
