GNOME Bugzilla – Bug 522810
Epiphany doesn't match FreeDesktop directories specs
Last modified: 2012-05-07 18:34:00 UTC
Please describe the problem: I found that Epiphany 2.22 (Ubuntu Hardy alpha 6) places its files in .gnome2/epiphany/ which doesn't match FreeDesktop directories specs : The default for $XDG_CONFIG_HOME is $HOME/.config, the default for $XDG_DATA_HOME is $HOME/.local/share. So all applications should look for those environment variables and use those default values if the variables are not set. See http://www.freedesktop.org/wiki/Specifications/basedir-spec See also - http://ploum.frimouvy.org/?184-cleaning-user-preferences-keeping-user-data (main post and comment#8) - http://www.aigarius.com/blog/2007/01/10/fhs-extension-for-user-home-folders/ Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Other information:
Epiphany-webkit 2.27.92 still doesn't match the spec Too bad to not use the swith gecko->webkit to fix it
Bug 504033 seems to be part of ths one
Hi, There has been a lot of progress concerning the Bug 523057 : [Tracking bug:] Match FreeDesktop directory specs, and it's pretty amazing to see the work that has been done across GNOME desktop. But Eiphany still doesn't comply the spec whereas it's a core app of GNOME... any plan to solve that bug ? Thanks
Created attachment 212844 [details] [review] Drop the use of GTK accel maps
Created attachment 212845 [details] [review] Migrate profile directory to XDG config dir
Review of attachment 212845 [details] [review]: We have a mechanism to do profile migrations in lib/ephy-profile-migrator.c. This should just be another step in there, seems to me.
Review of attachment 212844 [details] [review]: Is GTK+ going to drop this functionality? Also it does not seem to be related to the XDG dirs, so I guess it should go in another bug if we are going to discuss it.
Comment on attachment 212844 [details] [review] Drop the use of GTK accel maps Filed as https://bugzilla.gnome.org/show_bug.cgi?id=674870
Created attachment 212879 [details] [review] Migrate profile directory to XDG config dir
Review of attachment 212879 [details] [review]: Thanks, much better, just a few comments. ::: lib/ephy-profile-migrator.c @@ +35,3 @@ +#include <sys/stat.h> +#include <sys/types.h> +#include <fcntl.h> We put the system headers after the local app headers, sorted alphabetically. See HACKING. @@ +630,3 @@ +{ + if (g_file_test (old_dir, G_FILE_TEST_IS_DIR) + && !g_file_test (new_dir, G_FILE_TEST_EXISTS)) { Probably can just do an early check with this and bail out instead of having the whole method inside an if. @@ +654,3 @@ + res = write (fd, message, strlen (message)); + close (fd); + } I guess this is mostly nitpick, but any reason to use these posix-y methods instead of something like g_file_set_contents? @@ +675,3 @@ + NULL); + /* I don't think we can use ephy_dot_dir () here because + it might be a tmp profile */ We don't migrate temporary profiles (basically we only run this for normal non-private browser instances, see ephy_shell_startup), so I guess this does not apply. @@ +686,2 @@ const EphyProfileMigrator migrators[] = { + migrate_profile_gnome2_to_xdg, This needs to go at the end. There's a comment at the beginning of the file with some instructions, I guess they should be repeated here. You also need to increase the migration version in ephy-profile-utils.h, EPHY_PROFILE_MIGRATION_VERSION.
Created attachment 212911 [details] [review] Migrate profile directory to XDG config dir
Used the posix because I know it works (copied from nautilus). I don't think putting the profile migration at the end of the list will work since all of the other migrators will use the wrong dot_file in that case.
(In reply to comment #12) > Used the posix because I know it works (copied from nautilus). > > I don't think putting the profile migration at the end of the list will work > since all of the other migrators will use the wrong dot_file in that case. There's basically two possible scenarios here. - A user that has already gone through some migration steps (basically anyone that has used 3.0, 3.2, etc), and has an old profile in the old location. If you put the new step at position 0 he won't run it (you'll actually make him run again the last one in the list), so that's wrong. - A user that starts to use epiphany now. This case would work, but it would be also useless, since he would have no data to migrate in the old directory (it would not actually exist). Since we have to consider the other one as well, the patch as it is is wrong. Now, if we put the dir migration at the end, we get: - A user that has already gone through some migration steps. We just run the new step, the data is copied, nothing else to do. Good. - A user that starts to use epiphany now. The previous steps would try to migrate data from the new ephy_dot_dir(), which would not work. But the old directory (.gnome/epiphany) does not exist either, so I think this is basically irrelevant. A user that gets 3.6 as his first ephy won't have any passwords, cookies or history to migrate. At most what we need to do is double check that the old migration steps work correctly if the data we want to access does not exist. So sorry for the long comment, but it seems to me the right thing to do is actually to put the migration step at the end, as we usually do, and that even in this corner case it will work correctly. Am I missing any case?
(In reply to comment #13) > (In reply to comment #12) > > Used the posix because I know it works (copied from nautilus). > > > > I don't think putting the profile migration at the end of the list will work > > since all of the other migrators will use the wrong dot_file in that case. > > There's basically two possible scenarios here. > > - A user that has already gone through some migration steps (basically anyone > that has used 3.0, 3.2, etc), and has an old profile in the old location. If > you put the new step at position 0 he won't run it (you'll actually make him > run again the last one in the list), so that's wrong. So, I missed that you use this as an index. My mistake. No arguments on the two trivial end cases. > - A user that starts to use epiphany now. This case would work, but it would be > also useless, since he would have no data to migrate in the old directory (it > would not actually exist). Since we have to consider the other one as well, the > patch as it is is wrong. > > Now, if we put the dir migration at the end, we get: > > - A user that has already gone through some migration steps. We just run the > new step, the data is copied, nothing else to do. Good. I think you are missing a case here where the migration index is not zero and not latest but the old directory exists. In that case all of the migrations that should be done will move *some* data from the old directory to the new directory and then the final step will try to move the entire old directory to the new one and fail. Right? > - A user that starts to use epiphany now. The previous steps would try to > migrate data from the new ephy_dot_dir(), which would not work. But the old > directory (.gnome/epiphany) does not exist either, so I think this is basically > irrelevant. A user that gets 3.6 as his first ephy won't have any passwords, > cookies or history to migrate. At most what we need to do is double check that > the old migration steps work correctly if the data we want to access does not > exist. > > So sorry for the long comment, but it seems to me the right thing to do is > actually to put the migration step at the end, as we usually do, and that even > in this corner case it will work correctly. Am I missing any case? Yeah the middle one where more than one migration script is run. I think each of the migration scripts will try to do stuff with the wrong directory.
OK, so I think what we need to do here is just leave this out of the index system. In ephy_migrator() always run the "move stuff from the old dir to the new one" thing before entering the for() loop. That should be safe. Also, someone on IRC suggested that we should copy the data from the old dir, not rename it, that way old epiphany versions can still run in the same system.
*** Bug 652199 has been marked as a duplicate of this bug. ***
(In reply to comment #15) > Also, someone on IRC suggested that we should copy the data from the old dir, > not rename it, that way old epiphany versions can still run in the same system. That was me. I've been thinking about it and even though it is a good idea regarding backward compatibility, it actually brings one issue: by migrating, we're hoping to remove the mess in our home dir and if we just copy it, it will remain there.
(In reply to comment #17) > > That was me. I've been thinking about it and even though it is a good idea > regarding backward compatibility, it actually brings one issue: by migrating, > we're hoping to remove the mess in our home dir and if we just copy it, it will > remain there. Sure, but I think that's OK since you are upgrading an existing system. If you want to backup your data from now on you know you only need to copy the XDG dirs, and a newly installed system will be clean already. So I think that's not an issue.
OK. In the end I had to rework this again, since some refactoring was needed for file_helpers not to create the profile dir ahead of time. The cleanup was worthwhile though! Also in the end I left the rename behavior as it is, to be consistent with the other core apps. Users interested in running multiple ephys in the same machine can still copy data around.