Unable to copy files to Novell Netware drive - ncpfs Nautilus

Bug #224760 reported by Kim Tucker
28
Affects Status Importance Assigned to Milestone
GLib
Fix Released
Medium
Nautilus
Invalid
Medium
glib2.0 (Ubuntu)
Fix Released
Low
Ubuntu Desktop Bugs
Hardy
Fix Released
Medium
Ubuntu Desktop Bugs
ncpfs (Ubuntu)
Invalid
Medium
Unassigned
Hardy
Invalid
Medium
Unassigned

Bug Description

Problem arose after update to Hardy.

I can access (edit and save) and move files, and create folders on the mapped drives - but cannot copy files from my laptop for example.

Downgraded to a previous version of ncpfs (2.2.6-3) but that did not help.

Ubuntu 8.04
ncpfs 2.2.6-3
Nautilus 2.22.2-0ubuntu4

Drag (or cut and paste) (using Nautilus) a file from a local directory to a mapped Netware drive: expected a copy to appear on the mapped drive.

Instead:
<Alert>
 ! Error while copying to "<folder name>". There is not enough space on the destination. Try to remove files to make space.
... There is 0 bytes available, but 20.3 MB is required.
</Alert>

NB No problem with Konqueror or Thunar.

Revision history for this message
Alain Seemuller (alain-seemuller) wrote :

I made a fresh hardy install and have the same problem. The ncpfs package is not in faulty (it mounts the netware share and make it accessible). A copy command issued from a shell (cp anything /mnt/novell/) works just fine but dragging the same file in nautilus makes the above error message appear.

Revision history for this message
Alain Seemuller (alain-seemuller) wrote :

I've found a partial answer on Novell's site. They had the same problem with their OpenSuse and novfs:

"The main issue is the fact that if you run 'df', you'll see something like
this:

Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda5 73398648 9539964 63858684 13% /
udev 4155696 120 4155576 1% /dev
/dev/sda1 101086 11377 84490 12% /boot
/dev/sda6 10490040 533824 9956216 6% /var
10.0.5.13:/home 60815552 17467808 43347744 29% /home
novfs 0 0 0 100% /var/opt/novell/nclmnt

The reason why the nautilus plugin dies is because get_free_space() shows what df shows: 0 -- however, it is writable because there is free space, which is why Konqueror works, as well as the command line.

So I'll venture to bet that its novfs and has that nautilus is fine."

We can estimate too that, nautilus is fine and bet the bug has to do with ncpfs!

Maybe the developers should verify that the superblock i_blksize is not reset somewhere in the ncpfs code (maybe in a file handling inodes -- it was in inode.c for novfs).

Revision history for this message
tanas (macarvalho) wrote :

I confirm this problem in nautilis. In the shell it works perfectly.

Revision history for this message
Sebastien Bacher (seb128) wrote :

thank you for your bug report. does gvfs-copy copy the file correctly?

Changed in nautilus:
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: New → Incomplete
Revision history for this message
Kim Tucker (ktucker) wrote :

Yes, gvfs-copy works correctly.

Revision history for this message
Alain Seemuller (alain-seemuller) wrote :

gvfs-copy works well for me too

Revision history for this message
Sebastien Bacher (seb128) wrote :

there is http://bugzilla.gnome.org/show_bug.cgi?id=531743 upstream about that, though it seems that nautilus can't be really blame there and ncpfs seems rather buggy

Changed in nautilus:
status: Incomplete → Triaged
Changed in nautilus:
status: Unknown → New
Revision history for this message
Christian Neumair (chris-gnome-de) wrote :

According to the gio sources [g_local_file_query_filesystem_info()], we attempt to deal with this situation:

#if defined(__linux__)
  /* ncpfs does not know the amount of available and free space *
   * assuming ncpfs is linux specific, if you are on a non-linux platform
   * where ncpfs is available, please file a bug about it on bugzilla.gnome.org
   */
  if (statfs_buffer.f_bavail == 0 && statfs_buffer.f_bfree == 0 &&
      /* linux/ncp_fs.h: NCP_SUPER_MAGIC == 0x564c */
      statfs_buffer.f_type == 0x564c)
    no_size = TRUE;
#endif

This means that no size check should be made for ncpfs.

Maybe anybody could try to run

gvfs-info -f <some-file-on-ncpfs>

in a terminal?

Revision history for this message
A. Walton (awalton) wrote :

Except that inside of Nautilus, we explicitly check for space before doing the move (see nautilus-file-operations.c:verify_destination()) by querying the file system, so that we're sure we have space to complete the move and we don't have to abort midway through. Fundamentally, the filesystem is fubar if it can't tell us whether or not it has free space. We could special case it inside of Nautilus (check specifically for this filesystem and skip the space verification) or GIO (make it so that query_fs_info() always return MAX_UINT64 free space such that no copy/move will ever fail here) or wherever, but it's a very nasty hack, as a billion times to one, if the filesystem returns 0 for free space, it means "I have no space left".

Revision history for this message
Christian Neumair (chris-gnome-de) wrote :

> We could special case it inside of Nautilus (check specifically for this filesystem and skip the space verification)

This is GIOs job. We do not check for the required space if G_FILE_ATTRIBUTE_FILESYSTEM_FREE is not present. The onliest problem seems to be that the lack of this filesystem info is not properly propagated by GIO.

Revision history for this message
A. Walton (awalton) wrote :

Opened a bug for this, but it may still require a Nautilus change still. I'll have to check the code but I'm not sure we're handling the case in which this key doesn't exist properly at the moment.

Changed in glib:
status: Unknown → New
Revision history for this message
Christian Neumair (chris-gnome-de) wrote :

Here is an (untested) glib/GIO patch. It looks like the ncpfs condition has been detected but the result was ignored.

Revision history for this message
Dominique Hausser (dominique-hausser) wrote :

As requested by Christian Neumair:

 gvfs-info -f <ncprep/file>
attributes:
  filesystem::free: 0
  filesystem::size: 0
  filesystem::type: ncp

Revision history for this message
Christian Neumair (chris-gnome-de) wrote :

Dominique: Thanks, that seems to confirm the assumption that GIO propagates the free/size info although it is not meaningful.

Maybe somebody who actually uses ncpfs could test the patch I attached against the glib package? It should fix the issue. If it works, we can push it upstream.

Revision history for this message
Dominique Hausser (dominique-hausser) wrote :

I can test the patch. The only problem is I do not know how to implement it

Revision history for this message
Sebastien Bacher (seb128) wrote :

we can build a test package for you, what architecture do you use?

Changed in nautilus:
status: New → Confirmed
Revision history for this message
Dominique Hausser (dominique-hausser) wrote :

~$ lsb_release -rd
Description: Ubuntu 8.04
Release: 8.04

Yes I am really interested, thanks (as all my data are on ncp disk, as mentionned in bug 211238 and I am nautilus user more than konqueror ;-) question of daily practice).

Thanks a lot for your help

Revision history for this message
Sebastien Bacher (seb128) wrote :

this command doesn't tell us if you use i386 or amd64 or an another architecture

Revision history for this message
Dominique Hausser (dominique-hausser) wrote :

i386

Revision history for this message
Sebastien Bacher (seb128) wrote :

the deb contain the change mentioned before, could you give it a try?

Revision history for this message
Sebastien Bacher (seb128) wrote :
Revision history for this message
Dominique Hausser (dominique-hausser) wrote :

I tried with really the update. Still the problem: unable to copy size = 0

Revision history for this message
Christian Neumair (chris-gnome-de) wrote :

...and invoking gvfs-info still gives you the same output? It's really surprising that the proposed fix does not work.

Revision history for this message
bob23450 (bzanetti-deactivatedaccount) wrote :

Dominique, did you restart gnome (i.e. log out from the graphic shell and back in) after installing the package "really the update"? I did so and now it works fine for me.
gvfs-info output:

$gvfs-info -f /mnt/<scrubbed>
attributes:
  filesystem::type: ncp

Regards

Revision history for this message
Dominique Hausser (dominique-hausser) wrote :

Yes I restarted gnome, but Thursday is the date of update (with a script) and because the name of the package is the same, I tested with the old version.

I retested with more care, it works very well, thanks a lot

Too hard to think everything being a rather simple user....

Thanks again for your help, as all my data are on ncp disk.

Revision history for this message
Bolderbast (bolderbast-duckstad) wrote :

Hi,

I can also confirm that this is a working solution. Copying files to a NetWare server now works fine!

Unforunately however, after installing the "Really the update" DEB, synaptic reports it as "Broken" and I cannot install or remove any other packages.

I installed the DEB using "sudo dpkg -i libglib2.0-0_2.16.3-1ubuntu1_i386.deb".

Did I do something wrong?

Revision history for this message
Bolderbast (bolderbast-duckstad) wrote :

Whoops, I missed something.

It's not the "libglib2.0-0" package that is being reported as broken, but the "libglib2.0-0-dev" package. I suppose its depencies will have to be adjusted. I suppose this will be the case when the update(s) come through the repositories?

In the meanwhile, I removed the "libglib2.0-0-dev" package and all is working fine. Thanks!

Changed in nautilus:
status: Confirmed → Invalid
Revision history for this message
Sebastien Bacher (seb128) wrote :

that's not a ncpfs issue

Changed in glib2.0:
assignee: nobody → desktop-bugs
importance: Undecided → Medium
status: New → Confirmed
Changed in ncpfs:
importance: Undecided → Medium
status: New → Invalid
importance: Undecided → Medium
status: New → Invalid
Changed in glib:
status: New → Fix Released
Changed in glib2.0:
status: Confirmed → Fix Committed
Revision history for this message
Sebastien Bacher (seb128) wrote :
Changed in glib2.0:
status: Triaged → Fix Committed
status: Fix Committed → Triaged
Revision history for this message
Martin Pitt (pitti) wrote :

Accepted into -proposed, please test and give feedback here

Changed in glib2.0:
status: Triaged → Fix Committed
Revision history for this message
Stefan Soriga (sgstefan) wrote :

It's working now, thnx a lot.

Revision history for this message
Martin Pitt (pitti) wrote :

Copied to hardy-updates.

Changed in glib2.0:
status: Fix Committed → Fix Released
Revision history for this message
Alain Seemuller (alain-seemuller) wrote :

Thanks a lot for your reactivity. The patch works fine and it's nice to know there are people out there taking care of our problems in such a professionnal way.

Revision history for this message
Kim Tucker (ktucker) wrote :

Yes. Ditto. I second that. Thanks everyone!

Revision history for this message
andreasfreyer (freyer) wrote :

I hoped that the fix to this bug would also fix the problem that I have with vmware shared file systems - But it does not.

As discribed in the original bug description I can not copy onto a certain network drive because nautilus checks if the target filesystem has enough free space. With other file mangers (e.g. Thunar) it works fine.

When I check the target file system to whitch I want to copy/move a file I get the following result:
$ df -kh .
Filesystem Total Used Available Use% Mounted on
.host:/ 233G 85G 0 100% /mnt/hgfs

I installed the patch that was initiated by this Bug-Report without success. In the meanwhile I got an update via update manger of the newest version of the libglib2.0-0. But the bug still exists for vmware shared-filesystems.

My Environment:
VMware Host: Windows Vista
VMware Guest: Ubuntu Hardy 8.04 with gonme 2.22.1
VMware: Workstation 6.0
Plattform: I386

Why did the fix for the ncpfs-issue did not solve the vmware shared drive problem?

Revision history for this message
Christian Neumair (chris-gnome-de) wrote :

> Why did the fix for the ncpfs-issue did not solve the vmware shared drive problem?

Because it is another issue. Please file a new bug report and subscribe me.

Revision history for this message
Sebastien Bacher (seb128) wrote :

the issue is fixed in intrepid too

Changed in glib2.0:
status: Fix Committed → Fix Released
Changed in nautilus:
importance: Unknown → Medium
status: Invalid → Unknown
Changed in glib:
importance: Unknown → Medium
Changed in nautilus:
status: Unknown → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.