[long-term] ReactOS explorer file identification

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

MadRat
Posts: 243
Joined: Fri Feb 04, 2005 8:29 am
Contact:

Post by MadRat »

GreatLord wrote:I do not if this a good idea in reactos or not.

it scan frist three leters if it find sign MZ something it is a exefile
most file format have a signture at the begin of the file, to determent which file type it is. elf as elf at the begin of the file.

I think it good idea to keep dot and three lettter and implement this idea also. but I have not talk with any other dev about this idea.
The file extension is Wn16/DOS legacy, right?
*************************************
Go Huskers!
GreatLord
Developer
Posts: 926
Joined: Tue Nov 30, 2004 10:26 am
Location: Sweden

Post by GreatLord »

it is being use today in windows to know wich file type the file. windows does not look at the file type until you double click on it. if it is not a .exe at the end of the file it will not try execute it.
MadRat
Posts: 243
Joined: Fri Feb 04, 2005 8:29 am
Contact:

Post by MadRat »

I understand that part of it, but in all truth Windows does not use file extensions except for file execution. You can have a file extension around 60K characters long the way it works now. I believe the control panel applets are mapped out using another trick pointing to classname in the registry which is like 40-ish characters long surrounded by { and } and led by a period.
*************************************
Go Huskers!
user222
Posts: 62
Joined: Thu Mar 03, 2005 1:21 pm

Re: [long-term] ReactOS explorer file identification

Post by user222 »

mf wrote:The reason I pick < and >, is because these are illegal characters as a filename.
In a UNIX filesystem like EXT2 and EXT3 \:*?"<>| are not illegal characters in filenames.
MadRat
Posts: 243
Joined: Fri Feb 04, 2005 8:29 am
Contact:

Post by MadRat »

Theoretically, '/' and '\' are the only two characters that cannot appear in a filename - '/' because it's used to separate directories and files, and '\' because it terminates a filename.

http://www.npl.washington.edu/faq/unix-FAQ-2-2.html
*************************************
Go Huskers!
mf
Developer
Posts: 368
Joined: Mon Dec 27, 2004 2:37 pm
Location: Eindhoven, NL
Contact:

Post by mf »

MadRat wrote:Theoretically, '/' and '\' are the only two characters that cannot appear in a filename
Actually, even "" can - "\0" can't. If you want to access a file with a backslash on a unix system, it's as easy as:
cat some_file_with_\\_in_it
Where the first backslash escapes the next backslash, indicating it's part of the filename. Which already poses a problem for ReactOS if we ever want to implement unix filesystems (which we do), because windows/dos has not heard of character escaping. The only thing it knows is that a path between quotes is a single path instead of separated commandline parameters (which in the unix world gets solved with File\ with\ spaces).

So for special characters in strange filesystems (hell, doesn't HFS/HFS+ allow for slashes in a name?) we're screwed anyway. So that's not really an argument. In the windows world, / \ : * ? " < > | are all illegal characters. And if we ever encounter files with such names, god knows what may happen.
counting_pine
Posts: 237
Joined: Fri Nov 26, 2004 10:44 pm
Location: Fallowfield

Post by counting_pine »

What if ReactOS converted illegal filenames?
For example, IIRC, in web addresses, you sometimes see spaces replaced by %20.
So maybe ROS could do something similar. This could maybe be implemented in the file-system drivers?
MadRat
Posts: 243
Joined: Fri Feb 04, 2005 8:29 am
Contact:

Post by MadRat »

Is \0 a null character of some type?
*************************************
Go Huskers!
mf
Developer
Posts: 368
Joined: Mon Dec 27, 2004 2:37 pm
Location: Eindhoven, NL
Contact:

Post by mf »

MadRat wrote:Is \0 a null character of some type?
It's the filename delimiter in the filesystem.
Owen
Posts: 8
Joined: Sat Dec 11, 2004 6:03 pm
Contact:

Post by Owen »

My thoughts:

Good idea,

However: Wouldnt this be better handled by filesystems themselves?

Im thinking, right now we have HKCR\.ext, and under .ext we could place a optional mime-type key

Also, a reverse lookup table, like HKCR\mime\text\plain for example, would then have the same stuff as HKCR\.ext AND optionaly a file-extension key?

Then, When a program asks for files with the extension .exe, any PEs without that extension (For example: On an EXT FS) Would be treated as such by the FS

However, would it not be better to handle this at FS level, IE the EXT2 FS Driver does it, Fat not?

Also, the lookup system can convert a .txt file into the same file without .txt IF it has a text/plain mimetype

So D:\somefile.txt would be converted to D:\somefile on an EXT2 FS if the FS had a somefile on it. Obviously, D:\somefile.txt would be used if it existed.

However, should the FS driver by default trim extensions and set mime? Leave them? Leaving them would be easier, however on an EXT2 FS it may be preferable to trim?

Should this be disableable? On a whole system, drive or driver basis?

Theres still a lot to figure out!
Owen Shepherd - http://www.humgun.com
user222
Posts: 62
Joined: Thu Mar 03, 2005 1:21 pm

Post by user222 »

MadRat wrote:Theoretically, '/' and '\' are the only two characters that cannot appear in a filename - '/' because it's used to separate directories and files, and '\' because it terminates a filename.

http://www.npl.washington.edu/faq/unix-FAQ-2-2.html
Sorry, GNOME/Nautilus allows creating a file or folder with all the illegal characters, and KDE/Konqueror allows all the illegal characters except \. I think these are bugs in GNOME and KDE. The only "illegal" charaters allowed in filenames are "* : ?".
a2z
Posts: 7
Joined: Mon Mar 07, 2005 4:52 am

Post by a2z »

Here is how I would like this file type thing to be handled.

First, the OS knows when a file is added or altered, so any filetype determination can be done at that moment.

Same goes for newly mounted partitions: the OS could come back to the user (at the moment of mounting etc.) and ask whether it should scan it to determine filetypes. Or, the user could force it per file, folder or partition.

Any file type information (as well as any fine-grained security, ACl info) gets to be written in to the metadata for that file.

Since filetype determination is optional (per session or partition), any new files get the information added to their metadata at the time of content alteration or file creation.

I am sure there are holes in this scheme, but I hope it is a good start.
Floyd
Posts: 300
Joined: Sat Nov 27, 2004 7:45 am
Location: The frozen part of the USA

Post by Floyd »

counting_pine wrote:What if ReactOS converted illegal filenames?
For example, IIRC, in web addresses, you sometimes see spaces replaced by %20.
So maybe ROS could do something similar. This could maybe be implemented in the file-system drivers?
a space for windows is valid for file names but if you post a file with a space in it the webserver and browser converts it to a %20. i have tried to train the staff where i work not to use spaces but they don't get it.
pax mei amici amorque et Iesus sacret omnia
counting_pine
Posts: 237
Joined: Fri Nov 26, 2004 10:44 pm
Location: Fallowfield

Post by counting_pine »

Floyd wrote:
counting_pine wrote:What if ReactOS converted illegal filenames?
For example, IIRC, in web addresses, you sometimes see spaces replaced by %20.
So maybe ROS could do something similar. This could maybe be implemented in the file-system drivers?
a space for windows is valid for file names but if you post a file with a space in it the webserver and browser converts it to a %20. i have tried to train the staff where i work not to use spaces but they don't get it.
It's difficult for anyone who's never used a command line to appreciate how annoying spaces can be...

And, sorry, yeah, I know spaces are valid (in Windows) but it was about the only hex code I could recall at the time.
Obviously, it could extend to illegal characters, e.g.
"" -> %5C
"/" -> %2F
""" -> %22
"%" -> %25 or maybe %%
(Of course, it doesn't have to be "%". It could be any legal character. Even a number or a letter, if you're feeling particularly evil)
The only possible problem I can see with this is that file names could be potentially 3 times longer. This could be problematic if there's an upper limit on name/path lengths.
Post Reply

Who is online

Users browsing this forum: Bing [Bot] and 2 guests