GNOME Bugzilla – Bug 328266
"save a copy" deletes files
Last modified: 2007-01-13 13:21:08 UTC
evince-0.5.0-1 Using poppler 0.5.0 (splash) --- - "save a copy" overwrites files without confirmation 1. open file1.pdf 2. press ctrl-s, navigate to file2, select file2, press "save" --- --- - deleting file by saving it [lg@~]$ mkdir test [lg@~]$ cp doc/jacs004020.pdf test/ [lg@~]$ cd test [lg@test]$ ls -l total 632 -rw-rw-r-- 1 lg lg 642911 Jan 22 22:29 jacs004020.pdf [lg@test]$ evince jacs004020.pdf 1. press ctrl-s, select test/jacs004020.pdf, press "save" [lg@test]$ ls -l total 0 -rw-rw-r-- 1 lg lg 0 Jan 22 22:31 jacs004020.pdf --- --- -deleting the file by saving to symlink [lg@test]$ cp ../doc/jacs004020.pdf . [lg@test]$ ln -s jacs004020.pdf j.pdf [lg@test]$ ls -l total 632 lrwxrwxrwx 1 lg lg 14 Jan 22 22:36 j.pdf -> jacs004020.pdf -rw-rw-r-- 1 lg lg 642911 Jan 22 22:36 jacs004020.pdf [lg@test]$ evince jacs004020.pdf 1. press ctrl-s, select j.pdf, press "save" [lg@test]$ ls -l total 0 lrwxrwxrwx 1 lg lg 14 Jan 22 22:36 j.pdf -> jacs004020.pdf -rw-rw-r-- 1 lg lg 0 Jan 22 22:37 jacs004020.pdf you probably want to overwrite symlink, not a file ---
We need new api to make FileChooser automatically check this.
Created attachment 59542 [details] [review] Confirm before overwriting file, in GTK+ >= 2.8.0 I'm not sure if this is correct coding style - there are no other checks on GTK_MAJOR_VERSION and GTK_MINOR_VERSION in the code. If this is unacceptable, then I'm sure this could go in once the minimum GTK version supported is 2.8 or newer.
I've applied a bit modified patch to HEAD, thanks a lot.
evince-0.5.2 poppler-0.5.1 gtk2-2.8.10 -deleting file by saving it -deleting the file by saving to symlink are still valid. If i overwrite opened file (or symlink to this file) the file will be deleted.
I am not sure what comment #4 is about, aren't we asking for confimation? If so, why do you wonder that file is deleted if you've confirmed this delete?
What he means is that if you open "~/blah.pdf" and then save a copy of it to the same location (i.e., "~/blah.pdf"), the file is truncated to 0 bytes.
Ah, that is. Probably we need change the way we are saving a copy then.
I've changed Save a copy to do it in atomic way, so that we also avoid race conditions. It should be fixed in svn trunk now.