Bug 484001 - Please update to new version and apply a patch to workaround a redhat bug
Please update to new version and apply a patch to workaround a redhat bug
Status: CLOSED EOL
Product: Fedora EPEL
Classification: Fedora
Component: pmount (Show other bugs)
el5
All Linux
low Severity medium
: ---
: ---
Assigned To: Patrice Dumas
Fedora Extras Quality Assurance
UpdatePackage
:
Depends On: 500228
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-04 07:32 EST by Klaus Ethgen
Modified: 2017-04-06 06:30 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 500228 (view as bug list)
Environment:
Last Closed: 2017-04-06 06:30:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Fixed and updated pmount (429.05 KB, application/octet-stream)
2009-02-04 07:32 EST, Klaus Ethgen
no flags Details
update to latest and add patch (1.72 KB, patch)
2009-02-04 12:26 EST, Patrice Dumas
no flags Details | Diff
fixfor non utf8 locales (549 bytes, patch)
2009-02-04 12:28 EST, Patrice Dumas
no flags Details | Diff

  None (edit)
Description Klaus Ethgen 2009-02-04 07:32:29 EST
Created attachment 330857 [details]
Fixed and updated pmount

Description of problem:

Redhat kernel patch linux-2.6-defaults-fat-utf8.patch introduce a big bug when used in a non-UTF8-setup.

The patch utf8fix.patch in the srpm will work around that bug.

Additional I update the tool to the current version (Note that the URL has changed!)

Version-Release number of selected component (if applicable):
pmount 0.9.13

How reproducible:
Steps to Reproduce:
1. unset ALL language flags or use latin1 language flags
2. mount a vfat directory (usbstick) with german umlauts
  
Actual results:
You will see strange utf8 chars as the filesystem is mounted wrongly with utf8 option

Expected results:
You see the german umlaut or at least a '?'

Additional info:
Note that the main problem is a kernel bug that was made by RedHat (See #483622). This fix will also work with a fixed kernel.

Please also note that I did not change the name of the two patches from version 0.9.13 but I did a quilt refresh so the patches are cleanly applyable.
Comment 1 Patrice Dumas 2009-02-04 09:22:40 EST
You should start from the devel branch for the updates part, devel is already at 0.9.17. I plan to update to 0.9.18 soon.

The patch looks fine to me. It somehow relies on the fact that in utf8 locales the iocharset=%s from fs.c is not used, which confused me at first.

I am not sure that this solves every cases, though, since in utf8 locales the iocharset will be still be ignored. But this is more for the kernel bug.
Comment 2 Klaus Ethgen 2009-02-04 09:57:40 EST
O, 0.9.18 is the last released version in 2008-10-18. See http://alioth.debian.org/projects/pmount/.

When you look to pmount.c you can see that the utf8 flag is special handled in pmount.c (at least in 0.9.18). So the changes in fs.c only happens with non UTF8 locales or if not -c utf8 is specified. So the patch should solve every case.

And yes, this is a kernel bug, called linux-2.6-defaults-fat-utf8.patch.

To your confusion, I planed first to fix the error in pmount.c but as only the utf8 case is handled special and the normal case is specified in fs.c I decided to do it there more generic. That should be better than adding one more if construct.
Comment 3 Patrice Dumas 2009-02-04 12:26:43 EST
Created attachment 330892 [details]
update to latest and add patch
Comment 4 Patrice Dumas 2009-02-04 12:28:01 EST
Created attachment 330893 [details]
fixfor non utf8 locales
Comment 5 Patrice Dumas 2009-02-04 12:29:32 EST
Stepan, I attached an (untested) spec file patch for pmount devel and Klaus patch.

I think that this should be propagated to devel and to stable releases too.

I'll use it in epel too once it is in a stable release.
Comment 6 Patrice Dumas 2010-05-01 07:37:45 EDT
It seems that the kernel behaviour was changed in fedora 11 according to 500228#c4. So this is now an EL specific bug. However I tried to apply your patch, but unsuccesfully as it relies on changes, introduced at least in 

http://git.debian.org/?p=pmount/pmount.git;a=commitdiff;h=53648033f89819cbd53db802d91c287c9602db0b

and furthermore modified. I also poked at the changes, there are many changes, some that change somehow the behaviour (though not dramatically).

So, I'd better not update the version, so if you could rebase your patch somehow I could apply it. However, I guess that it isn't easy since the facilities that allow the patch to function are not available in the 0.9.13 code.

If you cannot make a patch, I'll update to 0.9.18 (or even later based on my reading of the diffs).
Comment 7 Klaus Ethgen 2010-05-01 09:22:19 EDT
Sure, I posted it as a EL specific bug. But tis makes it more urgent at all.

However, The patch shouldn't be bad for fedora 11 too. (I did not test, but the fix is that robust that there should be problemes.

About your problemes applying the patch, the patch only change one(!) line at all. I can not see where you find complexity in this single line. And the git commit you mention only change one line in fs.c which is not related to the patch at all. And I tried to apply the patch to the latest (master) version of pmount and it also apply without any problem at all.

So please tell me where you have the problems exactly.
Comment 8 Patrice Dumas 2010-05-01 10:06:30 EDT
(In reply to comment #7)
> Sure, I posted it as a EL specific bug. But tis makes it more urgent at all.
> 
> However, The patch shouldn't be bad for fedora 11 too. (I did not test, but the
> fix is that robust that there should be problemes.

It is not needed in F11 since the kernel patch was removed.

> About your problemes applying the patch, the patch only change one(!) line at
> all. I can not see where you find complexity in this single line.

No complexity. But it changes a line in a structure that was changed in the commitdif I point to:

 struct FS {
-    const char* fsname;    /* file system name (e. g. 'ext2') */
-    const char* options;   /* standard mount options (must not be empty) */
-    int support_ugid;      /* whether the fs supports uid and gid options */
-    const char* umask;     /* umask value (NULL if umask is not supported) */
-    int support_iocharset; /* whether the fs supports the iocharset option */
+  const char* fsname;    /* file system name (e. g. 'ext2') */
+  const char* options;   /* standard mount options (must not be empty) */
+  int support_ugid;      /* whether the fs supports uid and gid options */
+  const char* umask;     /* umask value (NULL if umask is not supported) */
+  int support_iocharset; /* whether the fs supports the iocharset option */
+  const char* iocharset_format;         
+  /* the format to be used for iocharset option -- NULL = iocharset=%s */
+  const char* fdmask_format;   /* how to actually implement the
+                                  fdmask_format. Takes two strings as
+                                  arguments
+                               */
+  int skip;              /* whether or not to skip this fs for detection */
 };

Your patch indeed changes the value of the 'const char* iocharset_format' field in a FS structure:

static struct FS supported_fs[] = {
...
   { "vfat", "nosuid,nodev,user,quiet,shortname=mixed", 1, "077", 
      ",utf8=0,uni_xlate,iocharset=%s",",fmask=%04o,dmask=%04o"},
 };

> And the git
> commit you mention only change one line in fs.c which is not related to the
> patch at all. 

look at the fs.h change.

> And I tried to apply the patch to the latest (master) version of
> pmount and it also apply without any problem at all.

Indeed. Your patch can be applied after the change in the structure and in the line you change:
http://git.debian.org/?p=pmount/pmount.git;a=commitdiff;h=2f919c7810403065904349aa2517febb8574f96c

Looks like you also want
http://git.debian.org/?p=pmount/pmount.git;a=commitdiff;h=ff860eb838c1e30872bfe650916f41eb0f1614cc

> So please tell me where you have the problems exactly.    

The epel version is 0.9.13. Ideally it is to that version that the patch should be applied. Now it may also be too complicated.

I had a look at all the diffs, the most problematic change may be the change in device link resolution -- though I cannot really assess what is at stake here. If you cannot provide a patch for 0.9.13, I'll update to 0.9.18.
Comment 9 Klaus Ethgen 2010-05-01 11:00:12 EDT
Ah, now I see your problem (a bit). There was no iocharset_format specifed for vfat post 0.9.16~7. However, the iocharset_format is specifed in the FS struct and can be specified also earlier. (The patch, you mention about is 0.9.16~8.)

However for earlier versions just enhance the {} for vfat.

Pre 0.9.16~7:
   { "vfat", "nosuid,nodev,user,quiet,shortname=mixed", 1, "077", 1,
     ",utf8=0,uni_xlate,iocharset=%s" },

Post 0.9.16~7:
   { "vfat", "nosuid,nodev,user,quiet,shortname=mixed", 1, "077", 
     ",utf8=0,uni_xlate,iocharset=%s",",fmask=%04o,dmask=%04o" },

However, you should nevertheless update to at least 0.9.18 (note especially 0.9.18~3..0.9.18~1) otherwise there are many problems with utf-8 on all systems (not only on latin1 systems) at all, with or without my patch! There are also some other minor fixes and improovements. See also "git log --decorate --reverse 0.9.13~1..0.9.18".

A short note, I do not have any EL system anymore so I cannot test it on EL.
Comment 10 Fedora End Of Life 2017-04-06 06:30:57 EDT
Fedora EPEL 5 changed to end-of-life (EOL) status on 2017-03-31. Fedora EPEL 5
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
or Fedora EPEL, please feel free to reopen this bug against that version. If
you are unable to reopen this bug, please file a new report against the current
release. If you experience problems, please add a comment to this bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.