The file extension is Wn16/DOS legacy, right?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.
[long-term] ReactOS explorer file identification
Moderator: Moderator Team
*************************************
Go Huskers!
Go Huskers!
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!
Go Huskers!
Re: [long-term] ReactOS explorer file identification
In a UNIX filesystem like EXT2 and EXT3 \:*?"<>| are not illegal characters in filenames.mf wrote:The reason I pick < and >, is because these are illegal characters as a filename.
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
http://www.npl.washington.edu/faq/unix-FAQ-2-2.html
*************************************
Go Huskers!
Go Huskers!
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:MadRat wrote:Theoretically, '/' and '\' are the only two characters that cannot appear in a filename
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.
-
- Posts: 237
- Joined: Fri Nov 26, 2004 10:44 pm
- Location: Fallowfield
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!
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
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 "* : ?".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
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.
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.
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.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?
pax mei amici amorque et Iesus sacret omnia
-
- Posts: 237
- Joined: Fri Nov 26, 2004 10:44 pm
- Location: Fallowfield
It's difficult for anyone who's never used a command line to appreciate how annoying spaces can be...Floyd wrote: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.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?
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.
Who is online
Users browsing this forum: Ahrefs [Bot], Bing [Bot] and 62 guests