Hello everyone,
I would like to participate in this year's google summer of code doing some work on case insensitive filenames ( http://wiki.winehq.org/CaseInsensitiveFilenames )
I have some experience working with FUSE ( see http://code.google.com/p/dejumble/ ).
Is there any formal process I must go through to enter google summer of code for wine?
Thanks.
Cesar Izurieta
Is there any formal process I must go through to enter google summer of code for wine?
Just filing Google's application will do, although you may want to crash in #winehackers .. What you should do IN TIME is to get intimate with the toolchain! That was the hardest part for me - getting started on WINE - but if you already have programming experience I doubt that is a problem. However, from personal experience of last years SoC, communicate your implementation ideas as early as possible and don't be afraid to ask for help here on the list would probably be the two most important things... And another lesson learned: it takes a lot of polish for your patches to be approved and committed by officer Julliard, be prepared to reiterate over your submitted code several times :D Else - go for it, task sounds reasonable achievable. And the t-shirt is really worth the effort :) regards
Thanks for your help. I'll prepare something and post it here for suggestions soon.
On Thu, Mar 6, 2008 at 12:27 PM, Marcel Partap mpartap@gmx.net wrote:
Is there any formal process I must go through to enter google summer of code for wine?
Just filing Google's application will do, although you may want to crash in #winehackers .. What you should do IN TIME is to get intimate with the toolchain! That was the hardest part for me - getting started on WINE - but if you already have programming experience I doubt that is a problem. However, from personal experience of last years SoC, communicate your implementation ideas as early as possible and don't be afraid to ask for help here on the list would probably be the two most important things... And another lesson learned: it takes a lot of polish for your patches to be approved and committed by officer Julliard, be prepared to reiterate over your submitted code several times :D Else - go for it, task sounds reasonable achievable. And the t-shirt is really worth the effort :) regards
--
<div id="signature"> "Obstacles are those frightful things you see when you take your eyes off your goal." -- Henry Ford (1863-1947) Change the world! Vote revolution: http://hfopi.org/vote-future </div>
Here are some ideas of what I think could be implemented for the FUSE project for GSOC.
- This FUSE can be a "proxy" filesystem. This means that we could use an existing filesystem and mount this proxy filesystem and make it appear as case insensitive. This means that if there's a file named "A.txt" on a folder and I copy "a.txt", "A.txt" should be overridden. Same logic for other cases.
- A utility to test for invalid filenames (like "A.txt" and "a.txt" on the same original directory)
- Is there any need to simulate windows' permission schemes (inheritance, ACLs) when using this filesystem?
- Since this will be a proxy filesystem, there is the chance to present some folders with different names. For example "Program Files" could be presented as "Archivos de Programa" when mounting the filesystem with a Spanish locale. The original folder will be still there and you could cd to it and both will point to the same back end folder.
If you have any other ideas please let me know.
Cesar
On Thu, Mar 6, 2008 at 6:47 PM, Cesar Izurieta cesar@ecuarock.net wrote:
Thanks for your help. I'll prepare something and post it here for suggestions soon.
On Thu, Mar 6, 2008 at 12:27 PM, Marcel Partap mpartap@gmx.net wrote:
Is there any formal process I must go through to enter google summer of code for wine?
Just filing Google's application will do, although you may want to crash
in #winehackers ..
What you should do IN TIME is to get intimate with the toolchain! That was
the hardest part for me -
getting started on WINE - but if you already have programming experience I
doubt that is a problem.
However, from personal experience of last years SoC, communicate your
implementation ideas as early
as possible and don't be afraid to ask for help here on the list would
probably be the two most
important things... And another lesson learned: it takes a lot of polish for your patches to
be approved and committed
by officer Julliard, be prepared to reiterate over your submitted code
several times :D
Else - go for it, task sounds reasonable achievable. And the t-shirt is
really worth the effort :)
regards
--
<div id="signature"> "Obstacles are those frightful things you see when you take your eyes
off your goal."
-- HenryFord (1863-1947)
Change the world! Vote revolution: http://hfopi.org/vote-future
</div>
On 3/23/08, Cesar Izurieta cesar@ecuarock.net wrote:
Here are some ideas of what I think could be implemented for the FUSE project for GSOC.
- This FUSE can be a "proxy" filesystem. This means that we could use
an existing filesystem and mount this proxy filesystem and make it appear as case insensitive. This means that if there's a file named "A.txt" on a folder and I copy "a.txt", "A.txt" should be overridden. Same logic for other cases.
- A utility to test for invalid filenames (like "A.txt" and "a.txt" on
the same original directory)
- Is there any need to simulate windows' permission schemes
(inheritance, ACLs) when using this filesystem?
- Since this will be a proxy filesystem, there is the chance to
present some folders with different names. For example "Program Files" could be presented as "Archivos de Programa" when mounting the filesystem with a Spanish locale. The original folder will be still there and you could cd to it and both will point to the same back end folder.
If you have any other ideas please let me know.
Cesar
Are you going to do integration under wine, or are you going to just do the file system. For instance, what happens if you run wine in a folder that isn't case insensitive?
On Thu, Mar 6, 2008 at 6:47 PM, Cesar Izurieta cesar@ecuarock.net wrote:
Thanks for your help. I'll prepare something and post it here for suggestions soon.
On Thu, Mar 6, 2008 at 12:27 PM, Marcel Partap mpartap@gmx.net wrote:
Is there any formal process I must go through to enter google summer of code for wine?
Just filing Google's application will do, although you may want to crash
in #winehackers ..
What you should do IN TIME is to get intimate with the toolchain! That was
the hardest part for me -
getting started on WINE - but if you already have programming experience I
doubt that is a problem.
However, from personal experience of last years SoC, communicate your
implementation ideas as early
as possible and don't be afraid to ask for help here on the list would
probably be the two most
important things... And another lesson learned: it takes a lot of polish for your patches to
be approved and committed
by officer Julliard, be prepared to reiterate over your submitted code
several times :D
Else - go for it, task sounds reasonable achievable. And the t-shirt is
really worth the effort :)
regards
--
<div id="signature"> "Obstacles are those frightful things you see when you take your eyes
off your goal."
-- HenryFord (1863-1947)
Change the world! Vote revolution: http://hfopi.org/vote-future
</div>
On Sun, Mar 23, 2008 at 6:11 PM, Corey McClymonds galeru@gmail.com wrote:
On 3/23/08, Cesar Izurieta cesar@ecuarock.net wrote:
Here are some ideas of what I think could be implemented for the FUSE project for GSOC.
- This FUSE can be a "proxy" filesystem. This means that we could use
an existing filesystem and mount this proxy filesystem and make it appear as case insensitive. This means that if there's a file named "A.txt" on a folder and I copy "a.txt", "A.txt" should be overridden. Same logic for other cases.
- A utility to test for invalid filenames (like "A.txt" and "a.txt" on
the same original directory)
- Is there any need to simulate windows' permission schemes
(inheritance, ACLs) when using this filesystem?
- Since this will be a proxy filesystem, there is the chance to
present some folders with different names. For example "Program Files" could be presented as "Archivos de Programa" when mounting the filesystem with a Spanish locale. The original folder will be still there and you could cd to it and both will point to the same back end folder.
If you have any other ideas please let me know.
Cesar
Are you going to do integration under wine, or are you going to just do the file system. For instance, what happens if you run wine in a folder that isn't case insensitive?
You could mount a case insensitive proxy to the whole file system (starting from /) somewhere in .wine, maybe .wine/drives/x or something like that and have wine access files only through .wine and never from outside.
I'm pretty sure this could have performance penalties but I guess we will have to find out how much performance you loose by using this approach using some benchmarking tools or writing some test code for that.
On Sunday 23 March 2008 17:06:43 Cesar Izurieta wrote:
Here are some ideas of what I think could be implemented for the FUSE project for GSOC.
- This FUSE can be a "proxy" filesystem. This means that we could use
an existing filesystem and mount this proxy filesystem and make it appear as case insensitive. This means that if there's a file named "A.txt" on a folder and I copy "a.txt", "A.txt" should be overridden. Same logic for other cases.
- A utility to test for invalid filenames (like "A.txt" and "a.txt" on
the same original directory)
Perhaps this shouldn't be an extra tool but more like a setting what to do in a case like that.
- Is there any need to simulate windows' permission schemes
(inheritance, ACLs) when using this filesystem?
Alexandre said that wasn't interesting until Wine goes multi-user. So don't worry about that for now.
- Since this will be a proxy filesystem, there is the chance to
present some folders with different names. For example "Program Files" could be presented as "Archivos de Programa" when mounting the filesystem with a Spanish locale. The original folder will be still there and you could cd to it and both will point to the same back end folder.
I'm not sure if that's really useful. IIRC wineprefixcreate already creates a localized directory layout.
Cheers, Kai
On Mon, Mar 24, 2008 at 8:28 AM, Kai Blin kai.blin@gmail.com wrote:
On Sunday 23 March 2008 17:06:43 Cesar Izurieta wrote:
Here are some ideas of what I think could be implemented for the FUSE project for GSOC.
- This FUSE can be a "proxy" filesystem. This means that we could use
an existing filesystem and mount this proxy filesystem and make it appear as case insensitive. This means that if there's a file named "A.txt" on a folder and I copy "a.txt", "A.txt" should be overridden. Same logic for other cases.
- A utility to test for invalid filenames (like "A.txt" and "a.txt" on
the same original directory)
Perhaps this shouldn't be an extra tool but more like a setting what to do in a case like that.
That sounds good. Maybe doing something like what windows does to long file names when looking those files in a console, for example "C:\Program Files" gets converted to "C:\Progra~1", we could apply the same logic, have the first file "A.txt" and the second "a~1.txt". What do you think?
- Is there any need to simulate windows' permission schemes
(inheritance, ACLs) when using this filesystem?
Alexandre said that wasn't interesting until Wine goes multi-user. So don't worry about that for now.
- Since this will be a proxy filesystem, there is the chance to
present some folders with different names. For example "Program Files" could be presented as "Archivos de Programa" when mounting the filesystem with a Spanish locale. The original folder will be still there and you could cd to it and both will point to the same back end folder.
I'm not sure if that's really useful. IIRC wineprefixcreate already creates a localized directory layout.
Cheers, Kai
-- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.
On Tuesday 25 March 2008 01:45:11 Cesar Izurieta wrote:
Perhaps this shouldn't be an extra tool but more like a setting what to do in a case like that.
That sounds good. Maybe doing something like what windows does to long file names when looking those files in a console, for example "C:\Program Files" gets converted to "C:\Progra~1", we could apply the same logic, have the first file "A.txt" and the second "a~1.txt". What do you think?
Well, that's probably an option. But I wouldn't even mind a mode that simply deletes one of A.txt or a.txt on mounting. If we start using a file system like that for ~/.wine/drive_c and people want to screw around in that directory manually, we can expect them to know what they're doing.
Cheers, Kai
On Tuesday March 25 2008 07:26:50 Kai Blin wrote:
On Tuesday 25 March 2008 01:45:11 Cesar Izurieta wrote:
Perhaps this shouldn't be an extra tool but more like a setting what to do in a case like that.
That sounds good. Maybe doing something like what windows does to long file names when looking those files in a console, for example "C:\Program Files" gets converted to "C:\Progra~1", we could apply the same logic, have the first file "A.txt" and the second "a~1.txt". What do you think?
Well, that's probably an option. But I wouldn't even mind a mode that simply deletes one of A.txt or a.txt on mounting.
Deleting files like that (just because of case insensitive match) on mounting is very, very bad idea. And I don't see any reason for such destructive actions. Better idea to pick up one and use it (for example, choice may be either pseudo-random or by alphabetical order where big letters comes first - latter is more preferable in my opinion because it let easily guess what file/directory will be used). However it is understandable and intuitive that if I have *already* mounted case-insensitive file system then I cannot create both A.txt and a.txt there. But this is safe because I can get a warning that I'm going to overwrite existing file.
On Tuesday 25 March 2008 13:18:59 L. Rahyen wrote:
Deleting files like that (just because of case insensitive match) on mounting is very, very bad idea. And I don't see any reason for such destructive actions. Better idea to pick up one and use it (for example, choice may be either pseudo-random or by alphabetical order where big letters comes first - latter is more preferable in my opinion because it let easily guess what file/directory will be used).
Ok, let's think about the use case here. My idea is that this is going to be used on a new WINEPREFIX on a call to wineprefixcreate. We create a new directory here and can make sure we're not doing anything stupid here. I'm not suggesting to use this for the whole file system. If I have two files with filenames that only differ in capitalization, this will only add confusion.
That's why I still think having an option to delete unwanted files is useful.
Cheers, Kai
On Tue, Mar 25, 2008 at 9:08 AM, Kai Blin kai.blin@gmail.com wrote:
Ok, let's think about the use case here. My idea is that this is going to be used on a new WINEPREFIX on a call to wineprefixcreate. We create a new directory here and can make sure we're not doing anything stupid here. I'm not suggesting to use this for the whole file system. If I have two files with filenames that only differ in capitalization, this will only add confusion.
That's why I still think having an option to delete unwanted files is useful.
An option yes, but it should not be the default course of action. As Rahyen said, a predictable order should be used, and when there are conflicts, pick the first in that order for presentation through the FUSE system. User can then rename files/delete files to get the one they want (or if possible, have a configuration menu to adjust chosen file order/allow exceptions, etc.).
On Tuesday 25 March 2008 17:21:20 Austin English wrote:
An option yes, but it should not be the default course of action. As Rahyen said, a predictable order should be used, and when there are conflicts, pick the first in that order for presentation through the FUSE system. User can then rename files/delete files to get the one they want (or if possible, have a configuration menu to adjust chosen file order/allow exceptions, etc.).
As long as it's configurable, I don't care about the default. I'm just concerned that the most important reason to use a case sensitive file system (i.e. not having to check for all possible capitalizations) will suffer from having to check if we're allowed to just overwrite or not will suffer.
How about simply refusing to mount if there's e.g. two files like foo and Foo? Then the user gets to clean up manually before being able to mount.
Cheers, Kai
On Tue, Mar 25, 2008 at 12:02 PM, Kai Blin kai.blin@gmail.com wrote:
On Tuesday 25 March 2008 17:21:20 Austin English wrote:
An option yes, but it should not be the default course of action. As Rahyen said, a predictable order should be used, and when there are conflicts, pick the first in that order for presentation through the FUSE system. User can then rename files/delete files to get the one they want (or if possible, have a configuration menu to adjust chosen file order/allow exceptions, etc.).
As long as it's configurable, I don't care about the default. I'm just concerned that the most important reason to use a case sensitive file system (i.e. not having to check for all possible capitalizations) will suffer from having to check if we're allowed to just overwrite or not will suffer.
How about simply refusing to mount if there's e.g. two files like foo and Foo? Then the user gets to clean up manually before being able to mount.
Cheers, Kai
-- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.
There could some sort of a warning and present the conflicted file with a different name. Depending on how efficient the checking is, it could take some time to traverse the whole file system (supposing we also mount the root / in .wine/something ). If that is the case we might need just to mount without checks and present the files with a different name when doing a directory listing.
On Tue, Mar 25, 2008 at 9:43 PM, Cesar Izurieta cesar@ecuarock.net wrote:
On Tue, Mar 25, 2008 at 12:02 PM, Kai Blin kai.blin@gmail.com wrote:
On Tuesday 25 March 2008 17:21:20 Austin English wrote:
An option yes, but it should not be the default course of action. As Rahyen said, a predictable order should be used, and when there are conflicts, pick the first in that order for presentation through the FUSE system. User can then rename files/delete files to get the one they want (or if possible, have a configuration menu to adjust chosen file order/allow exceptions, etc.).
Wouldn't it make the most sense to use whichever one was modified last? In most cases. that gives you the right response, eg. you put in a modified executable via patch or similar, and want it to use that version.
[snip]
-
Austin English -
Cesar Izurieta -
Corey McClymonds -
Kai Blin -
L. Rahyen -
Marcel Partap