Red Hat Bugzilla – Bug 822349
geeqie refuses to remove files on samba mounts
Last modified: 2013-09-02 16:24:21 EDT
Description of problem: When trying to delete a file on a samba mount, deletion is not allowed on a more local disk deletion is allowed other programs ant terminal can remove said files Version-Release number of selected component (if applicable): geeqie-1.0-13.fc16.i686 How reproducible: always Steps to Reproduce: 1. try to delete a file on a samba mount 2. 3. Actual results: deletion inhibited Expected results: file no more Additional info: Debug output yields 31.744055 (+00000.000045) read ahead cancelled for :null Change checked: OK: /mnt/photo/1.RAW/2012/04/2012-04-29-_POE4264.JPG The Dialog says: File Deletion failed External editor returned error status. File deletion failed /mnt/photo/1.RAW/2012/04/2012-04-29-_POE4264.JPG If i recall correctly (this was a while ago though), this behaviour is not seen on similar NFS mounts this problem is not very new but i just have not bothered to report it before
> a samba mount What sort of share is it? Public, guest, logon, what server, what mount options, what mount point? Could you attach an strace of such a file deletion attempt within Geeqie?
i'll try to get back with a trace later, in the meantime: it is a QNAP ts 119 NAS cut from /etc/fstab (with ids replaced by question marks: //komposten/foto on /mnt/photo type cifs (rw,nosuid,nodev,noexec,relatime,sec=ntlm,unc=\\komposten\foto,username=???,uid=???,forceuid,gid=???,forcegid,addr=192.168.1.11,file_mode=0755,dir_mode=0755,nounix,serverino,rsize=61440,wsize=65536,actimeo=1) i honestly do not know all the parameters above or why i set them at the time
Hmmm, "nounix" even. I don't know a test-case yet. Cannot reproduce so far with ordinary cifs mounts to either Samba or Windows servers.
Created attachment 585336 [details] strace of starting - changig directory and trying to delete a file (that fails)
| unlink("/mnt/photo/1.RAW/2012/04/2012-04-29-_POE4264.JPG") = -1 ETXTBSY (Text file busy) So, Geeqie asked the system to delete the file, but the system call returned -1, which is failure to delete the file due and an error condition. The ETXTBSY error number is strange, since that one means it's an executable file that's currently being executed.
If geeqie is running and looking at said file: [pontus@palsternacka ~]$ rm /mnt/photo/1.RAW/2012/04/2012-04-29-_POE4264.JPG rm: cannot remove `/mnt/photo/1.RAW/2012/04/2012-04-29-_POE4264.JPG': Text file busy [pontus@palsternacka ~]$ killall geeqie [pontus@palsternacka ~]$ rm /mnt/photo/1.RAW/2012/04/2012-04-29-_POE4264.JPG [pontus@palsternacka ~]$ and the file is removed (i do not know if this helps, but anyway) Doing the same in Nautilus works fine
Is it specific to the image that is being displayed? Can you delete other/undisplayed image files via the right-click menu of Geeqie's file browser column? If you display an image from that samba mount, does running "lsof|grep mnt/photo" (from package "lsof") show the image file as still being open inside geeqie? > Doing the same in Nautilus works fine Geeqie uses an mmap'ped image loader, which could make a difference. The upstream bug tracker doesn't list any problem as yours, however.
[pontus@palsternacka ~]$ cd /mnt/photo/1.RAW/2012/test2/ [pontus@palsternacka test2]$ ls -laZ drwxr-xr-x. pontus pontus system_u:object_r:cifs_t:s0 . drwxr-xr-x. pontus pontus system_u:object_r:cifs_t:s0 .. -rwxr-xr-x. pontus pontus system_u:object_r:cifs_t:s0 lookingatthisfile.JPG -rwxr-xr-x. pontus pontus system_u:object_r:cifs_t:s0 notlookingatthisfileeither.JPG -rwxr-xr-x. pontus pontus system_u:object_r:cifs_t:s0 notlookingatthisfile.JPG -rwxr-xr-x. pontus pontus system_u:object_r:cifs_t:s0 previouslywatched file.JPG [pontus@palsternacka test2]$ lsof |grep /mnt/photo geeqie 1890 pontus 7r REG 0,38 4370165 8809155002396 /mnt/photo/1.RAW/2012/test2/lookingatthisfile.JPG geeqie 1890 pontus 8r REG 0,38 7338642 8809155002399 /mnt/photo/1.RAW/2012/test2/notlookingatthisfileeither.JPG geeqie 1890 pontus 9r REG 0,38 4889078 8809155002397 /mnt/photo/1.RAW/2012/test2/notlookingatthisfile.JPG geeqie 1890 pontus 10r REG 0,38 6251524 8809155002398 /mnt/photo/1.RAW/2012/test2/previouslywatched file.JPG bash 1934 pontus cwd DIR 0,38 0 8809155002395 /mnt/photo/1.RAW/2012/test2 lsof 1974 pontus cwd DIR 0,38 0 8809155002395 /mnt/photo/1.RAW/2012/test2 grep 1976 pontus cwd DIR 0,38 0 8809155002395 /mnt/photo/1.RAW/2012/test2 lsof 1977 pontus cwd DIR 0,38 0 8809155002395 /mnt/photo/1.RAW/2012/test2 [pontus@palsternacka test2]$ rm * rm: cannot remove `lookingatthisfile.JPG': Text file busy rm: cannot remove `notlookingatthisfileeither.JPG': Text file busy rm: cannot remove `notlookingatthisfile.JPG': Text file busy rm: cannot remove `previouslywatched file.JPG': Text file busy [pontus@palsternacka test2]$
Created attachment 585592 [details] strace of last excercise and no rightclicking - choosing another file than the one being watched does not function either, but that is kond of apparent when looking at the bash results in above comment
> geeqie 1890 pontus 9r REG 0,38 > 4889078 8809155002397 > /mnt/photo/1.RAW/2012/test2/notlookingatthisfile.JPG It's still open for reading. That doesn't happen here. And all close() system calls in the first strace returned success. I guess for other directories (and other mounts), lsof does not list files as still open for you either.
i do not know whether i answer the right thing here but a lsof of watching pictures in my home directory shows no open files (and those can consequently be deleted without problems). (my knowledge is not that great, but) i understand that the problem is that the file is still opened by geeqie despite they should have been closed. do you reckon this is still a geeqie problem or a server (or other) ditto ? Since this only happens in geeqie (AFAIK) i tend to believe that it is a geeqie problem, but you OTOH - dos not see this on "similar" mounts.
(In reply to comment #11) ... > geeqie problem, but you OTOH - dos not see this on "similar" mounts. s/dos/you do/
Well, Geeqie does not care where your pictures are stored and whether that is on a local filesystem or on a mounted one. However, the filesystem's response to file related system calls could influence the code path in Geeqie or decide about whether what Geeqie does works (or is "compatible"). Also in your recent strace, one can, for example, look for the "notlookingatthisfileeither.JPG" and see that it is open()ed and close()d without error condition. One thing that might be a problem is the order of the open, mmap, close, munmap calls. Perhaps the close() call fails (despite the good return code 0), because the file is still mmap'ed, and munmap is called later. That's nothing I'd like to touch without a local test-case.
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
I have had the same problem with Geeqie as described above by Pontus Enhager, and I have found this bug report by looking for a solution. I also do have a samba server on a QNAP TS-1199 Turbo NAS, and my client is running openSuse 12.2/KDE, but I think the following applies to any distribution. Finally I found by myself a workaround/solution for this problem. In order to get Geeqie to be able to delete files on a samba share, mounted through cifs I came up with the following mount command in fstab: //[ip-samba-server]/[share] /[local mountpoint] cifs rw,uid=[local user], gid=[local group],file_mode=0666,nobrl,noserverino,nounix,forceduid, forcedgid,noperm,noauto,username=[username on samba-server] Pls. refer to the man-page mount.cifs for the meaning of these paramters. I am not sure (yet) if all these parameters are really required, but for sure the parameter "noserverino" did the trick, because as soon as I have added this one, Geeqie behaved on the samba share in the same way as it does on a local file system, incl. deleting files. Without this parameter I have noticed, that Geeqie always keeps on a samba share the last 4 files open which have either been activated in the Geeqie picture thumbnail browser or have actually been openend and closed in a new window. This can easily be tracked by lsof -u [user] | grep *.jpg And Geeqie always keeps ONLY the last 4 files open, so these last 4 files can also not be deleted by other applications. With "noserverino", Geeqie does NOT keep any files open, anymore. I believe this particular Geeqie behaviour occurs ONLY on certain samba server (smb.conf) configurations, as on QNAP-NAS's. Because, I have setup another (rudimentarily) samba server manually on an other "machine" (Raspberry PI), and there Geeqie worked fine from the very beginning even without the above sophisticated mounting parameters. There, Geeqie does not keep any files open. Hope this hint helps anyone having the same problem !