Could this be caused by hackfix method of detecting whether MyDocs isn't
currently available due to USB cable connection and mass storage mode enabled
(ie. unmounted partition)?

Adding myself to CC.

I think this is some kind of security check. If the user is able to save their
pictures in the root filesystem, "/", as "/home/user/MyDocs" in in there, they
would be able to fill the partition completely so the device would become
unusable since the OS is stored there, demanding a fresh firmware flash.

I would say this is INVALID.

(In reply to comment #2)
> Adding myself to CC.
> 
> I think this is some kind of security check. If the user is able to save their
> pictures in the root filesystem, "/", as "/home/user/MyDocs" in in there, they
> would be able to fill the partition completely so the device would become
> unusable since the OS is stored there, demanding a fresh firmware flash.
> 
> I would say this is INVALID.
>

/home/user is not in / but in the /home partition.
checking for free space on the destination mount point would be much
more reasonable than relying on a large mounted FAT partition.

(In reply to comment #2)
> I think this is some kind of security check. If the user is able to save their
> pictures in the root filesystem, "/", as "/home/user/MyDocs" in in there, they
> would be able to fill the partition completely so the device would become
> unusable since the OS is stored there, demanding a fresh firmware flash.

Internal memory is in ubifs. ext2/ext3 can not be used in internal memory
because it is mtd device not block device. So there is really no need to check
for free space, you only have to check that file system is not ubifs.
Using device that runs linux I expect that I can use native file system formats
on it without any limitations. So I think it is a bug and this report is valid.

I have same bug. 

I changed /home/user/MyDocs partition to ext3. And camera after taken first
picture closed with Failure message.

*** This bug has been confirmed by popular vote. ***

if phone has additional SD card (FAT32) than photo automatically saved on SD.
But even in this case if /home/user/MyDocs not FAT32 camera failed to take
pictures....

Comment 9 Eero Tamminen 2010-01-11 14:52:47 UTC

(In reply to comment #2)
> I think this is some kind of security check. If the user is able to save their
> pictures in the root filesystem, "/", as "/home/user/MyDocs" in in there, they
> would be able to fill the partition completely so the device would become
> unusable

And they wouldn't see the pictures after the real MyDocs is mounted on top of
it after USB cable is disconnected...

Comment 10 Eero Tamminen 2010-01-11 14:53:52 UTC

(In reply to comment #6)
> I changed /home/user/MyDocs partition to ext3. And camera after taken first
> picture closed with Failure message.

Does MyDocs still get mounted & unmounted properly in mass storage mode?

(In reply to comment #10)
> Does MyDocs still get mounted & unmounted properly in mass storage mode?
On Linux I can mount ext3 MyDocs without problems.
After that I have to remount MyDocs on device manually or change fstab.

Comment 12 Eero Tamminen 2010-01-11 19:38:01 UTC

(In reply to comment #8)
> if phone has additional SD card (FAT32) than photo automatically saved on SD.
> But even in this case if /home/user/MyDocs not FAT32 camera failed to take
> pictures....

But it works when MyDocs is FAT?


(In reply to comment #11)
> (In reply to comment #10)
> > Does MyDocs still get mounted & unmounted properly in mass storage mode?
> On Linux I can mount ext3 MyDocs without problems.
> After that I have to remount MyDocs on device manually or change fstab.

Ok, in that case the problem isn't probably in Camera, it's just tracking the
mounting signals and you're not sending one...?  (ke-recv mounts & unmounts
MyDocs, but it needs to make an assumption about the file system type, so it's
hardcoded to vfat, you need to change that too)

-> INVALID?

(In reply to comment #12)
> Ok, in that case the problem isn't probably in Camera, it's just tracking the
> mounting signals and you're not sending one...?  (ke-recv mounts & unmounts
> MyDocs, but it needs to make an assumption about the file system type, so it's
> hardcoded to vfat, you need to change that too)
Why camera need any mounting/unmounting signals?
I personally prefer to mount MyDocs from fstab and use it in /ext3.

> -> INVALID?
No!!!!

More simple just check available space on disk...
if it is enough than just start camera....

Additionally if MyDocs is not vfat camera just close without any messages. May
be better give message "not enough space on ...."

(In reply to comment #8)
> if phone has additional SD card (FAT32) than photo automatically saved on SD.
> But even in this case if /home/user/MyDocs not FAT32 camera failed to take
> pictures....

Why in this case camera check MyDocs?

Comment 15 Eero Tamminen 2010-01-12 16:01:49 UTC

(In reply to comment #13)
> Why camera need any mounting/unmounting signals?
...
> More simple just check available space on disk...

Read comment 9.


(In reply to comment #14)
> (In reply to comment #8)
>> if phone has additional SD card (FAT32) than photo automatically saved
>> on SD.  But even in this case if /home/user/MyDocs not FAT32 camera
>> failed to take pictures....
> 
> Why in this case camera check MyDocs?

Why do you think it checks that?

Was the SD card FAT32 properly mounted when you got this issue?

(In reply to comment #4)
> /home/user is not in / but in the /home partition.
> checking for free space on the destination mount point would be much
> more reasonable than relying on a large mounted FAT partition.
...

You are right, but /home/user is also used for installing application packages.
The N900 did a separation on storage devices and mount points taking into
account several things. In the case of the user personal files, as with the
camera generated media, there is a different volume to be used in
/home/user/MyDocs with the intention that it can be mounted automatically as an
external mass storage device in computers, for example. What you are requesting
is not following the general intention of the platform nor the specifically
taken into account for camera.

Maybe you want to save your pictures/videos y the volume mounted in /home/user
but, for the general user, that would be a problem as those files would
disappear once the volume used for /home/user/MyDocs is mounted again in its
place.

I agree with Eero comment 12, for me this bug is also INVALID, although I could
accept this bug to be reconsidered more as an enhancement request (still not
clear how camera should behave, though) than a real bug.

(In reply to comment #13)
...
> > -> INVALID?
> No!!!!
> 
> More simple just check available space on disk...
> if it is enough than just start camera....
...

I think the best thing we can do is to split this report in 2/3 bugs, because
we are mixing 2/3 scenarios:

1. Camera refuses to save any media when there is not external SD nor the
volume in /home/user/MyDocs mounted.

For me and Eero, this is INVALID. Read comment 9. Maybe it can be proposed like
a feature enhancement, although I really don't know how do you expect it to
work.

2. Camera fails to save media in non FAT32 volume mounted in /home/user/MyDocs

AFAIK, Camera doesn't check the system file format so this should be moved to
the proper component.

3. A non FAT32 volume is not mounted automatically back in /home/user/MyDocs.

The mount not working again is probably another problem in a different
component too. As Eero has explained in comment 12, if the user does this
manually, the proper event could be not arriving at Camera so it doesn't
realize the volume was mounted back.

Comment 18 Eero Tamminen 2010-01-12 17:52:25 UTC

(In reply to comment #17)
> 2. Camera fails to save media in non FAT32 volume mounted in /home/user/MyDocs
> 
> AFAIK, Camera doesn't check the system file format so this should be moved to
> the proper component.

I think this is user error.  The mounting needs to be done properly, in a way
that the system also knows it's mounted (through ke-recv).

wrong. The Camera works if I manually (without touching ke-recv)
mount a VFAT loopback file on MyDocs but not when I mount
an ext3 partition or loopback file on the same directory.
So this seems to be a VALID bug in the Camera app,
probably based on a very bad heuristic to check whether MyDocs
is currently exported.
If Camera app was open source (another bug...), we could easily fix it
ourselves...

(In reply to comment #18)
> (In reply to comment #17)
> > 2. Camera fails to save media in non FAT32 volume mounted in /home/user/MyDocs
> > AFAIK, Camera doesn't check the system file format so this should be moved to
> > the proper component.
> 
> I think this is user error.  The mounting needs to be done properly, in a way
> that the system also knows it's mounted (through ke-recv).

Comment 20 Andre Klapper 2010-01-12 18:02:48 UTC

(Can you please strip full quotes and answer below quotes? Readability.
Thanks.)

Comment 21 Eero Tamminen 2010-01-12 18:20:32 UTC

(In reply to comment #19)
> wrong. The Camera works if I manually (without touching ke-recv)
> mount a VFAT loopback file on MyDocs but not when I mount
> an ext3 partition or loopback file on the same directory.
...
> So this seems to be a VALID bug in the Camera app,

Hm.  You could try stracing camera application or monitoring D-BUS messages
when mounting VFAT & EXT3 to see what's the difference.

(Ext3 on MyDocs is not a product feature so unfortunately you need to do the
debugging for this, at least until the reason/"culprit" for the issue is more
clear.)

What about to resolve this problem in simplest linux way?
Just create /etc/camera-ui.conf file with possibility to setup:
1. Folder for pictures.
2. Check or not for mounting device. 
For normal users it will be default other will find this file. 
at least first what I did I tried to find camera.conf and camera-ui.conf

(In reply to comment #22)
> What about to resolve this problem in simplest linux way?
> Just create /etc/camera-ui.conf file with possibility to setup:
...

Just a quick comment about that. Maybe I'm too obtuse but, why would you like
to tune that?

I understand you prefer to use ext3 than FAT32 but, then, the problem is just
finding or enhancing the use of the volume mounted in /home/user/MyDocs to
support ext3, as it seems there are some problems because of that. Aside from
that, I don't see any benefit on not using the default volume and location.

(In reply to comment #23)
> I don't see any benefit on not using the default volume and location.
...

Unless you want to use the camera when the volume in /home/user/MyDocs is
mounted as an external mass storage device in a computer, which I think you
don't ...

Even in that case you could make use of the external SD or prevent mounting
that volume keeping an open file in the volume when requested to use the N900
as a mass storage device in your computer ...

I suppose I'm missing something :(

(In reply to comment #24)
> > I don't see any benefit on not using the default volume and location.

I can't believe you that you even ask such a question!
Why do most programs have a "Save as" function?
The camera app does not even offer such rudimentary features and
those are some of the reasons for people I know to return the N900 immediately
asking "WFT?!".
The possibility to choose whether pictures are stored on the eMMC or the SD
card
would be a simple everyday scenario.
But that's an independent feature enhancement...
The bug is that is it requires a FAT partition and therefore you can neither
put
a symlink DCIM to redirect the output nor a use mount bind.

(In reply to comment #25)
> (In reply to comment #24)
> > > I don't see any benefit on not using the default volume and location.
> 
> I can't believe you that you even ask such a question!
...

You haven't answered the question.

is "The possibility to choose whether pictures are stored on the eMMC or the SD
card would be a simple everyday scenario." not an answer?

(In reply to comment #26)
> You haven't answered the question.

(In reply to comment #27)
> is "The possibility to choose whether pictures are stored on the eMMC or the SD
> card would be a simple everyday scenario." not an answer?
> 
> (In reply to comment #26)
> > You haven't answered the question.
...

Mmmmm ... really, I should be missing something, because that's something that
can be done. There is no bug here :?

> The bug is that is it requires a FAT partition and therefore you can neither
> put a symlink DCIM to redirect the output nor a use mount bind.

Well, check comment 17, you will see I agree this is a bug.

About the bind mount, as you say in comment 19, it should be working if the
target volume is formatted as FAT32, so we go again to the same bug ... which,
AFAIK, is not placed in Camera-UI, but maybe I'm wrong.

(In reply to comment #27)
> is "The possibility to choose whether pictures are stored on the eMMC or the SD

Hi Thomas, 
if your /home/user/MyDocs is vfat and your SD card is vfat you can open camera
and press on button in a bottom which look like SD card. In the open menu you
can choose: 
1. Save picture on NOKIA... (it is mean /home/user/MyDocs/DCIM)
2. on SD card

Today I made test with unmounting /home/user/MyDocs and camera worked. Same
menu give only one option: Save on SD card.

Problem that if your /home/user/MyDocs is not vfat (and you didn't change where
to save pictures) camera application completely not working and you cannot
choose where to save picture.

Experiments with ext3 I am going to do on weekends....

oops. Thank you! I must have missed that one.
So we could change the independent "no-brainer" feature enhancement (not this
bug)
to adding an option "save to directory" to that list.

(In reply to comment #29)
> if your /home/user/MyDocs is vfat and your SD card is vfat you can open camera
> and press on button in a bottom which look like SD card.

Comment 31 Andre Klapper 2010-01-14 12:33:16 UTC

Today Nokia released the Maemo5 update version 2.2009.51-1 for public (also
called "PR1.1" sometimes).
If you have some time we kindly ask you to test again if the problem reported
here still happens in this new version - just leave a comment (and feel free to
update the "Version" field to the new version if it's still a problem).

there seems to be a workaround for the problem
http://talk.maemo.org/showpost.php?p=471150&postcount=56

Comment 33 Eero Tamminen 2010-01-14 19:20:19 UTC

(In reply to comment #32)
> there seems to be a workaround for the problem
> http://talk.maemo.org/showpost.php?p=471150&postcount=56

Not a very good workaround as according to the post it breaks mass storage mode
(i.e. you cannot simply plug your phone to your computer and import your
photos)?

yes, I know. The point was to show that Camera can in principle be tricked to
write on ext3. But apparently that leads to new problems
http://talk.maemo.org/showpost.php?p=472836&postcount=59

(In reply to comment #33)
> Not a very good workaround as according to the post it breaks mass storage mode

1. (In reply to comment #31)
> Today Nokia released the Maemo5 update version 2.2009.51-1 for public (also
> called "PR1.1" sometimes).
> If you have some time we kindly ask you to test again if the problem reported
> here still happens in this new version - just leave a comment (and feel free to
> update the "Version" field to the new version if it's still a problem).

I checked today camera with new update. It is now can be opened even if
/home/user/MyDocs is ext3. And I am able to change where to save it (Internal
memory or SD). At least if camera has vfat SD card camera could be used.

2. I modified ke-recv and now it is properly work with mounting and unmounting.
Result of commands are below.
    a) just after reboot:
# mount
rootfs on / type rootfs (rw)
ubi0:rootfs on / type ubifs (rw,bulk_read,no_chk_data_crc)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
tmpfs on /tmp type tmpfs (rw,noatime,size=1024k)
tmpfs on /var/run type tmpfs (rw,nosuid,noatime,size=256k,mode=755)
none on /dev type tmpfs (rw,noatime,size=10240k,mode=755)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,noatime,size=65536k)
/dev/mmcblk0p2 on /home type ext3
(rw,noatime,errors=continue,commit=1,data=writeback)
nodev on /sys/kernel/debug type debugfs (0)
/opt/pymaemo/usr/lib/python2.5 on /usr/lib/python2.5 type bind (bind)
/opt/pymaemo/usr/share/pyshared on /usr/share/pyshared type bind (bind)
/opt/pymaemo/usr/lib/pyshared on /usr/lib/pyshared type bind (bind)
/opt/pymaemo/usr/share/python-support on /usr/share/python-support type bind
(bind)
/opt/pymaemo/usr/lib/python-support on /usr/lib/python-support type bind (bind)
/dev/mmcblk0p1 on /home/user/MyDocs type ext3
(rw,noatime,errors=continue,commit=1,data=writeback)
/dev/mmcblk1p1 on /media/mmc1 type vfat
(rw,noauto,nodev,noexec,nosuid,noatime,nodiratime,utf8,uid=29999,shortname=mixed,dmask=000,fmask=0133,rodir)

  b) connect to computer (linux) in mass storage mode:
max-n900:~# mount
rootfs on / type rootfs (rw)
ubi0:rootfs on / type ubifs (rw,bulk_read,no_chk_data_crc)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
tmpfs on /tmp type tmpfs (rw,noatime,size=1024k)
tmpfs on /var/run type tmpfs (rw,nosuid,noatime,size=256k,mode=755)
none on /dev type tmpfs (rw,noatime,size=10240k,mode=755)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,noatime,size=65536k)
/dev/mmcblk0p2 on /home type ext3
(rw,noatime,errors=continue,commit=1,data=writeback)
nodev on /sys/kernel/debug type debugfs (0)
/opt/pymaemo/usr/lib/python2.5 on /usr/lib/python2.5 type bind (bind)
/opt/pymaemo/usr/share/pyshared on /usr/share/pyshared type bind (bind)
/opt/pymaemo/usr/lib/pyshared on /usr/lib/pyshared type bind (bind)
/opt/pymaemo/usr/share/python-support on /usr/share/python-support type bind
(bind)
/opt/pymaemo/usr/lib/python-support on /usr/lib/python-support type bind (bind)

c) disconnect from computer after step b)
  max-n900:~# mount
rootfs on / type rootfs (rw)
ubi0:rootfs on / type ubifs (rw,bulk_read,no_chk_data_crc)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
tmpfs on /tmp type tmpfs (rw,noatime,size=1024k)
tmpfs on /var/run type tmpfs (rw,nosuid,noatime,size=256k,mode=755)
none on /dev type tmpfs (rw,noatime,size=10240k,mode=755)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,noatime,size=65536k)
/dev/mmcblk0p2 on /home type ext3
(rw,noatime,errors=continue,commit=1,data=writeback)
nodev on /sys/kernel/debug type debugfs (0)
/opt/pymaemo/usr/lib/python2.5 on /usr/lib/python2.5 type bind (bind)
/opt/pymaemo/usr/share/pyshared on /usr/share/pyshared type bind (bind)
/opt/pymaemo/usr/lib/pyshared on /usr/lib/pyshared type bind (bind)
/opt/pymaemo/usr/share/python-support on /usr/share/python-support type bind
(bind)
/opt/pymaemo/usr/lib/python-support on /usr/lib/python-support type bind (bind)
/dev/mmcblk1p1 on /media/mmc1 type vfat
(rw,noauto,nodev,noexec,nosuid,noatime,nodiratime,utf8,uid=29999,shortname=mixed,dmask=000,fmask=0133,rodir)
/dev/mmcblk0p1 on /home/user/MyDocs type ext3
(rw,noatime,errors=continue,commit=1,data=writeback)

It is mean now my system correctly used ke-recv and all mounts and umounts I
can do in "nokia" way. 
But camera is HARDCODED FOR FAT32!!!! after performing following commands: 
max-n900:~# umount /media/mmc1 
max-n900:~# mount
rootfs on / type rootfs (rw)
ubi0:rootfs on / type ubifs (rw,bulk_read,no_chk_data_crc)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
tmpfs on /tmp type tmpfs (rw,noatime,size=1024k)
tmpfs on /var/run type tmpfs (rw,nosuid,noatime,size=256k,mode=755)
none on /dev type tmpfs (rw,noatime,size=10240k,mode=755)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,noatime,size=65536k)
/dev/mmcblk0p2 on /home type ext3
(rw,noatime,errors=continue,commit=1,data=writeback)
nodev on /sys/kernel/debug type debugfs (0)
/opt/pymaemo/usr/lib/python2.5 on /usr/lib/python2.5 type bind (bind)
/opt/pymaemo/usr/share/pyshared on /usr/share/pyshared type bind (bind)
/opt/pymaemo/usr/lib/pyshared on /usr/lib/pyshared type bind (bind)
/opt/pymaemo/usr/share/python-support on /usr/share/python-support type bind
(bind)
/opt/pymaemo/usr/lib/python-support on /usr/lib/python-support type bind (bind)
/dev/mmcblk0p1 on /home/user/MyDocs type ext3
(rw,noatime,errors=continue,commit=1,data=writeback)

I start camera and took picture. It is show me "Processing Image" and one
second later "operation failed" and camera was closed.

I resolve this problem!!!!
Now my camera can took pictures on ext3 and vfat!!!!

I resolved it by modification ke-recv (I will try too put patch somewhere...). 
But camera has bug too.....

Bug is: 
When camera start it is checking on presence folder DCIM on target partition.
If it doesn't exist camera create folder DCIM. Here is a bug!
DCIM created with root:root (group and user) but should be user:users.

Like way around (until nokia will fix it) could be change owner:group by
command: 

chown -R user:users DCIM
chmod -R 664 DCIM

After this camera make picture on ext3 partition!!!
Quality of pictures absolutely same!

full script for this: 
1. Turn on Camera
2. Change Location for saving picture on internal memory
3. Make picture. Camera will be closed with error message.
4. in terminal type:
    chown -R user:users DCIM
    chmod -R 664 DCIM

After this camera will work.

Comment 37 Eero Tamminen 2010-01-19 16:15:55 UTC

(In reply to comment #36)
> Bug is: 
> When camera start it is checking on presence folder DCIM on target partition.
> If it doesn't exist camera create folder DCIM. Here is a bug!
> DCIM created with root:root (group and user) but should be user:users.

Then it's not camera app, but maybe the daemon:
#ps |grep cam                                                      
  786 root     14976 S    /usr/sbin/omap3camd -d /dev/video0 -f /tmp/omap3camd0 
  862 root     14732 S    /usr/sbin/omap3camd -d /dev/video1                    
 2574 user      3936 S    /usr/bin/camera-ui                                    
 2575 user     54828 S    /usr/bin/camera-ui 

Can you mount Ext3 so that files are created as owned by user (at least on FAT
you can specify this)?

(In reply to comment #37)
> (In reply to comment #36)
> > Bug is: 
> > When camera start it is checking on presence folder DCIM on target partition.
> > If it doesn't exist camera create folder DCIM. Here is a bug!
> > DCIM created with root:root (group and user) but should be user:users.
> 
> Then it's not camera app, but maybe the daemon:
> #ps |grep cam                                                      
>   786 root     14976 S    /usr/sbin/omap3camd -d /dev/video0 -f /tmp/omap3camd0 
>   862 root     14732 S    /usr/sbin/omap3camd -d /dev/video1                    
>  2574 user      3936 S    /usr/bin/camera-ui                                    
>  2575 user     54828 S    /usr/bin/camera-ui 
> 
> Can you mount Ext3 so that files are created as owned by user (at least on FAT
> you can specify this)?
> 
in general if you have working ke-recv (i filled bug on it) camera work. But
when camera started and folder DCIM don't exist camera create new DCIM with
wrong owner and group. it is only for ext3 because fat don't have owner

AFAIK, from what i could understand from the camera-ui developers the call used
to create the directory /home/user/MyDocs/DCIM, in the case it does not exits
when camera app starts, is internally calling to "mkdir". The man page of mkdir
command clearly specifies that the new directory may have the ownership of its
parent directory, depending on the mounting options:

"The  newly  created  directory will be owned by the effective user ID of the
process.  If the directory containing the file has the set-group-ID bit set, or
if the file system is mounted with BSD group semantics  (mount  -o  bsdgroups 
or, synonymously mount -o grpid), the new directory will inherit the group
ownership from its parent; otherwise it will be owned by the effective group ID
of the process."

Comment 40 Eero Tamminen 2010-01-20 19:04:07 UTC

(In reply to comment #39)
> "The  newly  created  directory will be owned by the effective user ID of
> the process.  If the directory containing the file has the set-group-ID bit
> set, or if the file system is mounted with BSD group semantics  (mount  -o 
> bsdgroups or, synonymously mount -o grpid), the new directory will inherit
> the group ownership from its parent; otherwise it will be owned by the
> effective group ID of the process."

Mount resets the directory user & group:

# umount MyDocs/
# chown user.users MyDocs
# chmod u+s MyDocs
# ls -lad /home/user/ /home/user/MyDocs/
drwxr-xr-x   32 user     users        4096 Jan 20 18:54 /home/user/
drwsr-xr-x    2 user     users        4096 Sep 17 11:48 /home/user/MyDocs/
# mount MyDocs                                             
# ls -lad /home/user/MyDocs/                   
drwxrwxrwx   10 user     root        65536 Jan  1  1970 /home/user/MyDocs/

Because they're explicitly set as mount options:
# mount                                                    
...
/dev/mmcblk0p1 on /home/user/MyDocs type vfat
(noauto,nodev,noexec,nosuid,noatim
e,nodiratime,utf8,uid=29999,shortname=mixed,dmask=000,fmask=0133,rodir)

And while it's mounted, they cannot be modified:
# chmod u+s MyDocs/
chmod: MyDocs/: Operation not permitted

But they get restored when VFAT is unmounted.
# umount MyDocs/
# ls -lad /home/user/MyDocs/
drwsr-xr-x    2 user     users        4096 Sep 17 11:48 /home/user/MyDocs/

What happens with Ext3?

(In reply to comment #39)
> AFAIK, from what i could understand from the camera-ui developers the call used
> to create the directory /home/user/MyDocs/DCIM, in the case it does not exits
> when camera app starts, is internally calling to "mkdir". The man page of mkdir
> command clearly specifies that the new directory may have the ownership of its
> parent directory, depending on the mounting options:
> 
> "The  newly  created  directory will be owned by the effective user ID of the
> process.  If the directory containing the file has the set-group-ID bit set, or
> if the file system is mounted with BSD group semantics  (mount  -o  bsdgroups 
> or, synonymously mount -o grpid), the new directory will inherit the group
> ownership from its parent; otherwise it will be owned by the effective group ID
> of the process."

That's the problem. call for mkdir in Camera has analog "sudo mkdir" or some
preparation made under "root:root". After this preparation finished camera try
to save picture with "user:users". For FAT it is not a problem because FAT
don't have permissions. 
P.S. For ext3: on most of linux (at least ubuntu and debian) if you will call
"sudo mkdir /home/User/test" directory test will have "root:root" and it don't
depend from owner of folder User.

Comment 42 Eero Tamminen 2010-01-20 19:15:46 UTC

(In reply to comment #41)
> That's the problem. call for mkdir in Camera has analog "sudo mkdir" or some
> preparation made under "root:root".

I assume the directory is done by omap3camd which runs as root:
# ps|grep cam                                              
  786 root     14976 S    /usr/sbin/omap3camd -d /dev/video0 -f /tmp/omap3camd0 
  862 root     14732 S    /usr/sbin/omap3camd -d /dev/video1

It needs to be run as root to access the video device files, those aren't user
readable.


> P.S. For ext3: on most of linux (at least ubuntu and debian) if you will call
> "sudo mkdir /home/User/test" directory test will have "root:root" and it don't
> depend from owner of folder User. 

Right, I forgot that...

Max, are you sure you are starting the camera-ui application as normal user ? 
It should be started using the DSME tools, dsmetool -t /usr/bin/camera-ui. As
far as i know the directory is created using a regular mkdir call; considering
the camera-ui app is being run as user i don't no see how the DCIM directory
has root ownership.

(In reply to comment #43)
> Max, are you sure you are starting the camera-ui application as normal user ? 
> It should be started using the DSME tools, dsmetool -t /usr/bin/camera-ui. As
> far as i know the directory is created using a regular mkdir call; considering
> the camera-ui app is being run as user i don't no see how the DCIM directory
> has root ownership. 
> 
Yes.
At least I didn't change anything with camera. I just open camera. I don't use
manual start.
ps | grep camera 
give: 
1125 user    3936 S    /usr/bin/camera-ui
1126 user    54268 S    /usr/bin/camera-ui

(In reply to comment #5)
> you only have to check that file system is not ubifs.

It can't be on /home either (comment 16), but checking the filesystem type
isn't quite right IMHO.  Maybe just stat(2) the DCIM directory and check that
its st_dev is not on ubi (major 254) or /dev/mmcblk0p2 (major 179, minor 2)?

(In reply to comment #40)
> And while it's mounted, they cannot be modified:
> # chmod u+s MyDocs/
> chmod: MyDocs/: Operation not permitted

Same on any subdirectory, because chmod(2) always gets EPERM when trying to set
any of the setuid, setgid or sticky bits on VFAT (the nosuid mount option is
redundant actually).

> What happens with Ext3?

Pretty much the same (mounting masks the parent fs's version of the mount point
with the mounted fs's root dir) except that POSIX owner/group/perms are fully
functional.

(In reply to comment #42)
> It needs to be run as root to access the video device files, those aren't user
> readable.

Well, if it runs as root it could chown the directory after creating it.  That
will even succeed on VFAT if chowning to the same uid defined in the mount
option.

(In reply to comment #45)
> It can't be on /home either (comment 16), but checking the filesystem type
> isn't quite right IMHO.  Maybe just stat(2) the DCIM directory and check that
> its st_dev is not on ubi (major 254) or /dev/mmcblk0p2 (major 179, minor 2)?

please don't. Those are all poor heuristics which are likely to fail sooner or
later
(esp. if a power user doesn't want to have vfat).

ke-recv knows when and which partitions or SD cards are USB exported
or mounted. It should send notifications (dbus?) to camera-app
to disable/enable storage of pictures on certain target locations.
Camera app may create the DCIM folder but it should also try
to chmod it to user:user, as creating user data folder as uid=0
is generally a bad idea.

Rechecking the whole story ...

(In reply to comment #36)
...
> Bug is: 
> When camera start it is checking on presence folder DCIM on target partition.
> If it doesn't exist camera create folder DCIM. Here is a bug!
> DCIM created with root:root (group and user) but should be user:users.
...

You must be mistaken, I've just checked this and, if you are not running
camera-ui directly as superuser (which actually I think you won't be able, no
matter what), camera-ui is running as user and the new DCIM directory is
created correctly as user.users.

But, it is true that there is a problem. The newly created directory has the
following permissions:

d--------x    2 user     users        4.0k Feb 10 23:36 DCIM

And this is the actual bug in camera-ui. However, a problem easy to avoid just
setting the right permissions, as you have said.

The other problem ...

(In reply to comment #46)
> (In reply to comment #45)
> > It can't be on /home either (comment 16), but checking the filesystem type
> > isn't quite right IMHO.  Maybe just stat(2) the DCIM directory and check that
> > its st_dev is not on ubi (major 254) or /dev/mmcblk0p2 (major 179, minor 2)?
...

AFAIK, camera-ui is not checking for the file system, as I've already stated
before. The problem you are facing is related to the feature that camera-ui
should save the pictures in the external SD or in the internal MMC which can be
mass mounted in another computer. It seems camera-ui is checking whether there
is a partition mounted in /home/user/MyDocs different from the one mounted in
/home . It doesn't check the filesystem. As you can check, if you would have a
VFAT partition mounted in /home and none in /home/user/MyDocs, camera-ui will
claim not to have an internal memory in which to save the pictures too.

For me, this is not a bug but an arguable feature enhancement. Again, I suggest
to open a new and different bug for this case, not related *at all* with the
file system type.

...
> please don't. Those are all poor heuristics which are likely to fail sooner or
> later
> (esp. if a power user doesn't want to have vfat).
> 
> ke-recv knows when and which partitions or SD cards are USB exported
> or mounted. It should send notifications (dbus?) to camera-app
...

AFAIK, ke-recv would not tell you which partitions are mass mounted and which
not, it will, as best, tell you that "some" partition is mass mounted, so you
cannot trust in ke-recv. Not sure, though.

(In reply to comment #47)
> It seems camera-ui is checking whether there is a partition mounted in /home/user/MyDocs
> different from the one mounted in /home .

according to max this not the case, as camera-ui can save the pictures to a
MyDocs/DCIM folder on /home as long as the permissions are fixed (correct me,
if I'm wrong).

> > ke-recv knows when and which partitions or SD cards are USB exported
> > or mounted. It should send notifications (dbus?) to camera-app
> AFAIK, ke-recv would not tell you which partitions are mass mounted and which
> not, it will, as best, tell you that "some" partition is mass mounted, so you
> cannot trust in ke-recv. Not sure, though.

ke-recv calls osso-usb-mass-storage-enable.sh and specifies the partition as a
parameter.
(file ke-recv.c)

(In reply to comment #48)
...
> according to max this not the case, as camera-ui can save the pictures to a
> MyDocs/DCIM folder on /home as long as the permissions are fixed (correct me,
> if I'm wrong).
...

I've already checked that. Maybe I'm wrong, although I doubt it ... let's wait
for his feedback.

...
> ke-recv calls osso-usb-mass-storage-enable.sh and specifies the partition as a
> parameter.
> (file ke-recv.c)
...

Does it report this in some way so the rest of apps can know it (DBus)? Also,
you have to take into account that waiting for ke-recv events would be slower
than receiving them directly from HAL/DBus ... Just guessing ...

Comment 50 Andre Klapper 2010-02-17 21:09:44 UTC

This has been fixed in the internal build version
10.2010.07-3
(Note: 2009/2010 is the year, and the number after is the week.)

A future public update released with the year/week later than this internal
build version will include the fix. (This is not always already the next public
update.)
Please verify that this new version fixes the bug by marking this bug report as
VERIFIED after the public update has been released and if you have some time.

To answer popular followup questions:
 * Nokia does not announce release dates of public updates in advance.
 * There is currently no access to these internal, non-public build versions.
   A Brainstorm proposal to change this exists at
http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/

Comment 51 Andre Klapper 2010-03-15 20:54:29 UTC

Setting explicit PR1.2 milestone (so it's clearer in which public release the
fix will be available to users).

Sorry for the bugmail noise (you can filter on this message).