From: Miklos Szeredi <miklos@szeredi.hu> This patch adds a new open flag, O_NODE. This flag means: open just the filesystem node instead of the object referenced by the node. Opening a file will not call the driver's ->open() method and will not have any side effect other than referencing the dentry/vfsmount from the struct file pointer. Currently O_NODE can only be used together with O_NOACCESS (value 3), meaning that read(2) and write(2) will return EBADF and no permission is neces...

This seems to make it work in the chroot. It turns around the logic, and installs the libs in /usr, and moves the .so to /, so the devel links and the .la files are not changed. Thanks, Kay diff --git a/shlibs/blkid/src/Makefile.am b/shlibs/blkid/src/Makefile.am index 8b1f46b..b585f0a 100644 --- a/shlibs/blkid/src/Makefile.am +++ b/shlibs/blkid/src/Makefile.am @@ -21,7 +21,7 @@ AM_CPPFLAGS += -I$(ul_libblkid_srcdir) $(common_cflags) blkidincdir = $(includedir)/blkid blkidinc_HEADERS =...

My choice is to provide the option of those to users. I'm not saying to Now, I'm not working for any companies. I can say there is no closed I'm just thinking about users. If vendors shipped the buggy code like first buggy patch, I just thought it's more bad for our users. That's all. If there is community decision, I'll be really glad to follow it. Thanks. -- OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> --

Hi Jan, I should also mention that in the first patch I sent back in May, I added some code that made the 8.3 name problem easier on the user. It basically forced the shortname= option, overriding the mount option, when the patch was triggered. The end result was that a name like dcis3000.jpg would always be stored as a 8.3 name, and thus be visible to digital cameras, even if the mount options were set to say that lowercase names should be considered as "long" names. Hirofumi objected, on the b...

> I have no objection to improve. And in this case, for this option, to > force the shortname= sounds reasonable. Great! Which varient of this would you prefer I implement? I think the two obvious choices are: 1) do what I did in the May patch, which is to force VFAT_SFN_CREATE_WINNT when the patch code triggers. 2) force VFAT_SFN_CREATE_WINNT, but also if the name is mixed case within either prefix or extension (such as "Mixed.TXT") then force that part of the name to all ...

Hi Jan, > The cam does not have a problem with long filenames,A $,1rt That is curious. When you use a long filename (ie. a real long filename, not a mixed case 8.3 name), if you ask the camera for details on the photo, does it show the long filename you chose, or does it show a 8.3 "mangled" name, like ABC~01.JPG. > as said, it works on any to-date vanilla/distro Linux kernel, > which, if I understood mount(8) right, always create a long > filename due to me using a lowercas...

Hi Jan, > No-no, as previously mentioned it ignores filenames not in the > format of dscf????.jpg. But if I interpret the hexdump right, > standard Linux creates a long name *anyway*, even for names > fitting in 8.3, if it's lowercase: > > $,2 "00bce510 79 39 79 39 03 00 f5 5b-79 39 95 4b 00 00 00 00 |y9y9? ?[y9?K | > $,2 "00bce520 41 67 00 6f 00 64 00 64-00 61 00 0f 00 27 6d 00 |Ag o d d a ? 'm | > $,2 "00bce530 6e 00 2e 00 7a 00 69 00-70 00 00 00 00...

Hi Jan, > Right. That in itself is fine, but I'd still like to have readdir > return lowercase names here then. you are in luck! It just so happens that this is what happens when we use the patch that Hirofumi and I just agreed on (ie. the case handling part of my patch from May, combined with the current patch). I include it below. Can you please test it? It should be applied on top of the previous patch. Note that you will not need to specify shortname=winnt. In fact, if you don'...

No special options — all defaults to whatever the Linux kernel and util-linux 2.14.1 gave me. Whereby util-linux should not make a difference because it just passes on the mount request for there is no special vfat helper. Given my second report about the audio player (just sent out), I even compared dualnames=n with =y on the same kernel — which would rule out changed defaults between 2.6.29 and 2.6.31-rc. /proc/mounts contains, on .31-rc: /dev/sdc1 /mnt vfat rw,relatime,fmask=0022,...

The mount(8) manpage becomes pretty ambiguous with the dualnames patch. By default, "store a long name when the short name is not all upper case" would apply - and is invoked because I am a lazy typist who wrote "cp $this dscf3000" instead of "cp $this DSCF3000". Now since dualnames=n is in effect, no long name would need to be written because it still fits into 8.3 — subsequently, one would assume an Making WINNT the default would cause many a `ls` output to just scream at me in uppercaps b...

There is no misleading in that, since VFAT is rather case-insensitive. Certainly, lowering all 8.3 names is more appalling to the eyes than keeping all-caps-longnames that way. I think I would even add a new heuristic for case transformation on display to fit my personal guidelines which would be: ($file, $ext) = ($filename =~ /^(.*)\.(.*)$/); $ext = lc $ext; if ($file =~ /^[A-Z]+$/) { $file = lc $ext; } Linux has been doing case conversion all years long so I do not think ...

Hi Jean-Pierre, Thank you for testing this patch. To compile on 2.6.29 just add this line to fuse_i.h: The patch should work on 2.6.30 or later without problems. Or you can try 2.6.31-rc1-git10 from www.kernel.org, which already has this patch applied. Thanks, Miklos --