|
From: SourceForge.net <no...@so...> - 2012-04-30 08:14:48
|
Bugs item #1803073, was opened at 2007-09-26 14:23 Message generated for change (Comment added) made by jarekczek You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1803073&group_id=588 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: editor core Group: severe bug Status: Open Resolution: None Priority: 7 Private: No Submitted By: Vitaliy Berdinskikh (skipper13) >Assigned to: Jarek Czekalski (jarekczek) Summary: "Backup on every save" resets file permissions. Initial Comment: If I tick "Two stage save" - owner and group of file changed. If I don't tick this option - owner and group change again. After restart application. After reopen file. Linux blackbeard.tortuga.co.ua 2.6.22-ARCH #1 SMP PREEMPT Thu Sep 20 19:43:47 CEST 2007 i686 AMD Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux java version "1.6.0_02" Java(TM) SE Runtime Environment (build 1.6.0_02-b05) Java HotSpot(TM) Client VM (build 1.6.0_02-b05, mixed mode, sharing) jEdit4.3pre10 ---------------------------------------------------------------------- >Comment By: Jarek Czekalski (jarekczek) Date: 2012-04-30 01:14 Message: Currently the backup is done by renaming the old file to a backup file. I suggest replacing renaming with copying. It will be more costly than renaming, but when the user turns on the backups, it means he prefers safety to speed. I will do it if no one objects. ---------------------------------------------------------------------- Comment By: Alan Ezust (ezust) Date: 2012-01-17 17:51 Message: re-opening... Thinking about it some more, there is no reason jEdit needs to do a rename every time it performs backups. It could just write new files as backups, owned by the user of jEdit, and not change the way it saves, and work properly for more people than it does now. ---------------------------------------------------------------------- Comment By: Alan Ezust (ezust) Date: 2012-01-17 17:47 Message: I added a tooltip that says "resets file permissions" when you hover over the option. ---------------------------------------------------------------------- Comment By: Kazutoshi Satoda (k_satoda) Date: 2010-06-05 04:38 Message: I guess the reason of this behavior that making a backup during a save request does rename (as far as possible). After that, the actual file is opened to save the contents, where the file is created as a new file, which means the default user and group is set for the file. ---------------------------------------------------------------------- Comment By: Lindsey Simon () Date: 2010-06-02 12:08 Message: I have this problem too - oddly I did not have it before my recent upgrade to Lucid, but maybe it just never affected me for some reason? But this is severe indeed. I can't work on files in my web server directory - they are intermittently, but consistently, getting chown'd and having the group permission bit changed such that I have to run a shell script to recursively fix it. That is a productivity killer. I've noticed the same effect when saving files over fuse. I've ticked and unticked the Two stage save, but as the original post mentions it seems not to help. In my About JEdit I have: JEdit 4.3.1 server mode Java 1.6.0_18 ---------------------------------------------------------------------- Comment By: George (gapop) Date: 2008-11-28 12:33 Message: I have the same problem. The owner is always reset to my_user:my_group, while the file is initially owned by my_user:www_group. So now every time I save a buffer in jEdit I have to do a chown, otherwise Apache won't be able to read the file. Disabling or enabling the "two-stage save" feature doesn't make any difference. Ubuntu 8.10, Sun Java SE Runtime Environment 1.6.0_10, jEdit 4.3pre16. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1803073&group_id=588 |