On 1 Sep 04 at 15:59, Peter Astrand wrote:
> > > * Some files are impossible to remove, for example the files in
> > > ~/.kde/socket-dhcp-253-234: An unlink returns EBUSY:
> > >
> > > unlink("kdeinit_maggie_2") = -1 EBUSY (Device or resource busy)
> > >
> > > Do you have any ideas what can cause this? Do you consider ncpfs stable
> > > enough to be used for the home directory?
> >
> > File is open... You cannot remove opened files from Netware filesystem.
> > I cannot think about any other reason why you should get EBUSY.
>
> It might have something to do with open files, but in that case, the
> behaviour is not consistent. I've just did a quick test with "cat
> > foo.txt", and was able to delete the file while it was still open:
>
> # ls -l /proc/21642/fd
> ...
> l-wx------ 1 adam 1000 64 Sep 1 15:39 1 -> /home/adam/foo.txt (deleted)
> ...
ncp_unlink closes file on server if there is no read or write
operation in progress - see ncp_make_open, ncp_inode_close and
ncp_make_closed: ncp_make_open opens file on server, ncp_inode_close
marks file as being "closable" and ncp_make_closed closes file unless
someone is in ncp_make_open - ncp_inode_close region.
Cannot be kdeinit_maggie_2 opened by someone else?
BTW, ncpfs is "single threaded" because protocol itself is single
threaded - you can have only one outstanding request. Even with TCP
transport which could allow more than one outstanding request, leaving
synchronization on TCP level, if you send data to server while
it processes another request some server versions return back 9999,
server busy, instead of leaving received data in the queue until
previous request is satisfied :-(
Actually with 2.6.x fs/ncpfs/sock.c changing code to not call
ncp_abort_connection() when something goes wrong should not be that
hard. Only problem is that ncp_request_reply structure is allocated
on caller stack, and so you must kill receiver (ncpdgram_rcv_proc/
ncptcp_rcv_proc) before you release this structure.
But main question is whether it is really needed... It works this way
since day #1 (old kernels actually used SIGKILL|SIGSTOP, making
debugging of processes using ncpfs filesystem almost impossible, yet
nobody complained).
Petr Vandrovec
> > > > unlink("kdeinit_maggie_2") = -1 EBUSY (Device or resource busy)
> ncp_unlink closes file on server if there is no read or write
> operation in progress - see ncp_make_open, ncp_inode_close and
> ncp_make_closed: ncp_make_open opens file on server, ncp_inode_close
> marks file as being "closable" and ncp_make_closed closes file unless
> someone is in ncp_make_open - ncp_inode_close region.
>
> Cannot be kdeinit_maggie_2 opened by someone else?
Not another machine. This server currently allows only one NCP connection.
I have no idea which KDE processes that are opening this file, though.
> BTW, ncpfs is "single threaded" because protocol itself is single
> threaded - you can have only one outstanding request. Even with TCP
> transport which could allow more than one outstanding request, leaving
> synchronization on TCP level, if you send data to server while
> it processes another request some server versions return back 9999,
> server busy, instead of leaving received data in the queue until
> previous request is satisfied :-(
I guess it would be possible to use multiple TCP/NCP connections, but this
might be a bit overkill.
> Actually with 2.6.x fs/ncpfs/sock.c changing code to not call
> ncp_abort_connection() when something goes wrong should not be that
> hard. Only problem is that ncp_request_reply structure is allocated
> on caller stack, and so you must kill receiver (ncpdgram_rcv_proc/
> ncptcp_rcv_proc) before you release this structure.
>
> But main question is whether it is really needed... It works this way
> since day #1 (old kernels actually used SIGKILL|SIGSTOP, making
> debugging of processes using ncpfs filesystem almost impossible, yet
> nobody complained).
I can only speak for myself, but I do believe that this is a big problem
for us and our customers. I've filed a bug in the Bugzilla: Bug 3328.
--
Peter ?strand Chief Developer
Cendio http://www.thinlinc.com
Teknikringen 3 http://www.cendio.se
583 30 Link?ping Phone: +46-13-21 46 00