So you've got reiser4 there care of the hitchhiker -hh patch set, which is a -gentoo fork, right? Do you have another kernel you can check against? If you can find a -vanila+reiser4 kernel or similar then we can remove the -gentoo vendor patchset as a variable and isolate the reiser4 <-> GLib interaction

AfC

I just upgraded only glib and reproduced the issue so we found the exact package causing it.

By the way Gedit works but, EOG, Nautilus doesn't how do they differ in file creation?

I also wrote a sample gio file copy program which works as well.

Reiser4 patchset had known problems with syncing data to disk, resulting in oops. Try some 2.6.33 patchset, at least 2.6.33-zen1 works fine here.

Sorry for the late answer I missed the mail from bugzie. Anyway I tried 2.6.33-zen2 and that doesn't work either :(

Any other stuff to investigate?

Hi just want to add my five cents: I also have a kernel 2.6.34.4 with gentoo patches and reiser 4 patches, and this is still happening.

Until this gets fixed, is there a workaround? e.g. using earlier version of nautilus? It's really causing me problems as none of my files are being saved!

Seems like glib 2.24 is the error and we're stuck on GNOME 2.28 :(

(In reply to comment #8)
> Seems like glib 2.24 is the error and we're stuck on GNOME 2.28 :(

Can you specify what is the error exactly? Glib does nothing more than using POSIX calls, there should not be any difference when using other non-glib based apps.

(In reply to comment #9)
> (In reply to comment #8)
> > Seems like glib 2.24 is the error and we're stuck on GNOME 2.28 :(
> 
> Can you specify what is the error exactly? Glib does nothing more than using
> POSIX calls, there should not be any difference when using other non-glib based
> apps.

Not all glib applications fail either, I happen to hit it with Nautilus and Eye of GNOME, but not with a simple gio copy call. It doesn't give an error either you just blindly end up with a null file. How can I simulate nautilus file copy programatically?

I'll try to add some test cases to debug.

As describe above, there is no error. Copying a file or doing 'save as' from several gnome apps (e.g. evince) creates a new file, which is empty i.e. 0 bytes. Don't think it's a problem at the disk level, as you can still use 'cp' from the shell without any probs. However, it's a real pain as I keep on forgetting this happens and fail to save files.

Created attachment 169599 [details]
a simple copy example to demonstrate problem

The target and the source being my home directory which resides in a reiser4 partition, this file copy just works.

(In reply to comment #12)
> Created an attachment (id=169599) [details]
> a working copy example
> 
> The target and the source being my home directory which resides in a reiser4
> partition, this file copy just works.

I'm afraid I still have a problem in this case. copying a file f from ~/ to ~/d/ doesn't work. It is created empty.

Confirming, just tested on my gentoo box running 2.6.35-zen2, dev-libs/glib-2.24.1. Tested copying about 700MB in 4000 files produced all zero sized files, using GIO functions, including nautilus and gvfs-copy. POSIX cp and also mc copied all files just fine. 

Saving files in gedit works fine. No messages in dmesg. Strange that 'du' shows correct sizes.

Will test in Fedora tomorrow.

(In reply to comment #13)
> I'm afraid I still have a problem in this case. copying a file f from ~/ to
> ~/d/ doesn't work. It is created empty.
I was tricked by the display of the leftout thumbnail, yes it doesn't work for me either.

Reproducible on Fedora as well. I suspect our splice change causing pain. Going to look at this in the coming weeks.

As per reiser4 upstream comment[1] can we disable splice use on reiser4 targets. We may need to get bug #617245 fixed.
 
1: http://marc.info/?l=reiserfs-devel&m=128431393307748&w=2

Thanks,
Serkan

Any chance that this is fixed/worked-around for GNOME 3?

Could somebody confirm whether this is a bug in gvfs or the reiser4 kernel driver? I saw you made a post on the r4 mailing list, but couldn't quite understand whether the problem is in their drivers.

(In reply to comment #19)
> Could somebody confirm whether this is a bug in gvfs or the reiser4 kernel
> driver? I saw you made a post on the r4 mailing list, but couldn't quite
> understand whether the problem is in their drivers.

It's because glib started using splice for file copying and reiser4 doesn't support it.

Can comment #17 be done as the referred bug is fixed. The situation improved a tiny bit since my last comment. In 2.6.36 the filesize attribute is correctly copied but file contents are still not.

Regards,
Serkan

Created attachment 179001 [details] [review]
Patch to avoide splice usage for reiser4 targets.

I'm adding a patch to do what I said in comment #17.

I really, really think the reiser4 implementation needs to be patched to at a minumum, return -EINVAL if they can't be bothered to implement the better interfaces.

Created attachment 179003 [details] [review]
Patch to avoide splice usage for reiser4 targets.

Here's a patch against master.

It should be explicitly noted that glib actually has already been doing the right thing and handling -EINVAL from the kernel on a splice() call.

(In reply to comment #23)
> I really, really think the reiser4 implementation needs to be patched to at a
> minumum, return -EINVAL if they can't be bothered to implement the better
> interfaces.

Yes, indeed. This is only a workaround.

I'm little afraid of this additional sync I/O operation, potentially affecting performance, causing delays before the operation starts. Though my fears may be false due to negligible impact.

Created attachment 185354 [details] [review]
Patch to avoide splice usage for reiser4 targets.

Created attachment 186515 [details] [review]
Patch to avoide splice usage for reiser4 targets.

Is this still a problem with the latest kernel? I don’t want to add a workaround in GLib if the problem in reiserfs has been fixed in the last 6 years.

The upstream kernel sources seem to have a generic splice implementation for it, which I assume should work (or return EINVAL correctly):

https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/tree/fs/reiserfs/file.c#n256

The kernel git logs are unsurprisingly quite unhelpful at indicating whether splice support has been fixed or changed in the last 6 years.

---

On the assumption that this *has* been fixed since anybody last complained about it (or everyone’s stopped using reiserfs), I’m going to close this bug. Please re-open it if there’s still an issue. Thanks.

Please note reiserfs != reiser4, it's a separate implementation. Also reiser4 still hasn't been mainlined, being distributed as an external patch.

(In reply to Tomas Bzatek from comment #31)
> Please note reiserfs != reiser4, it's a separate implementation. Also
> reiser4 still hasn't been mainlined, being distributed as an external patch.

Ah, I see. Thanks for the information. In that case, upstream GLib is definitely not going to start working around problems in reiser4. If any distros are carrying the reiser4 patch in their kernel, they can carry their own GLib patch too.