GNOME Bugzilla – Bug 109767
Changes made to files in an archive should update the archive
Last modified: 2008-04-12 09:45:39 UTC
Feature request: When an archived file is opened and edited from within file-roller, changes made to the file should be saved in the archive. This would be really usefull when you work with recursive archives, like ear's containing jar's containing an xml file you need to change... For an example, see Emacs archive-mode.
Created attachment 27604 [details] [review] This patch fixes makes the corresponding enhancement. When the patch is applied, file-roller detects and updates changes to files modified with an external application.
Created attachment 27958 [details] [review] This is a patch file with a ChangeLog entry
Created attachment 28036 [details] [review] This patch fixes a small bug in my previous patch.......i apologize for the inconvenience Compression and Update parameters should not be hardcoded as in previous patch and should be obtained from FRWindow
Two notes: 1) Use window_archive_add to add files to the archive. 2) This patch doesn't work very well with gedit (and maybe other programs too) that when there is already an instance of itself running does not keep the new process running but simply signals the already running process to open the file in a new tab, thus when the process exits you cannot be sure that the user was finished editing the file. However I think the confirmation dialog you did is enough to fix this problem.
I think looking at the modification time of the currently open files should solve the bug in a better way. A timeout function to check the modification of the files might be needed to achieve that. The files could be maintained in a GPtrArray. Any Comments?
I feel that we could provide two options to the user - "update" and "ignore". BUT apart from these another CHECKBUTTON could also be provided that states that all modifications to this file must be ignored.
Created attachment 31307 [details] [review] This patch provides a better solution
What about just passing a gz:#tar:/// URI to the program and let gnome-vfs deal with it? I know this would mean improving the gnome-vfs handlers, but it would solve the problem, at least for gnome-vfs supporting apps.
Ubuntu bug about that: https://launchpad.net/distros/ubuntu/+source/file-roller/+bug/61878 "Editing files in file-roller causes data loss Binary package hint: file-roller When editing files in file-roller changes can be lost. How to reproduce: 1. Double click zip file in nautilus (create one text file and archive it if needed) 2. Double click file in file-roller to open it up in an editor 3. Make some changes in file 4. Save changes (do not save in another folder) 5. Close editor and file-roller Now changes will be effectively lost and cannot be retrieved back anymore. Fix proposal: Remove user write access on temporary directory created by file-roller (in /tmp directory)" Changing the bug settings, that's not a wishlist because changes are dropped
*** Bug 337820 has been marked as a duplicate of this bug. ***
I've just lost few hours of work because of this bug. Could priority and severity of this issue be promoted to higher level? Keeping track of extracted/viewed files does not seem to be that dificult ;) I would expect functionality similar to WinZip on Windows system. BTW: There is another related issue I noticed: - if you view the same file while it is already being viewed, File Roller creates another instance of the file, it should rather bring up original one or at least give warning that file is already opened (and maybe modified). Best Regards, GW, xubuntu 7.10 xfce, File Roller 2.20.1
the current development version (in the trunk branch) implements this feature.
this feature is available since version 2.22.0