Re: [platform-update-dev] Help wanted ...

[klicnik@xxxxxxxxxx]

> There are three methods needed:-

> int getFreeSpace( File path);
> String getLabel( String path);
> int getType( File path);

There are actually 4 methods needed, but only the 3 listed have a direct 
native mapping. 

The fourth is actually a callback to fireRootChanged(File path) which 
would be a notification from the natives that part of the file system has 
changed. The primary intent of the last one was ability to detect a CD 
being inserted. But could also map to new mount, some other removable 
device being "activated", etc. It is likely that it may not be easy to 
detect all kinds of these events on the various platforms. So the primary 
support is the CD/ DVD case, the others are a bonus if they can be 
supported. The "File path" argument would be the logical file path 
representing the root directory  of the changed file subtree. It has been 
pointed out to me that the implementation of the callback may require 
different threading structure than what is in 0305 (eg. get the callback 
notification, but then execute the actual listener calls on a separate 
Java thread). Also, that splitting the one callback into added/ removed/ 
changed events may be better. We can adjust the Java side accordingly.

> Well the first question is what is going to be passed as the path. 
Ignoring
> for the moment why one takes a String and the other two Files, what is 
this
> path going to represent.  Is it the logical path (/mnt/cdrom) or the 
physical
> path (/dev/hdb).  It should not matter greatly, but it would be nice to 
know.

All of the listed calls in 0305 take File as the argument (the getLabel 
returns String, but takes File). I was going say that the path is logical, 
but I guess now that you ask, the path could be either. In our Java code 
we do File.listRoots() and then walk the directory structure. 
File.listRoots() returns / on Linux, and I am fairly sure both /mnt and 
/dev will appear as children when we walk. The intent is to represent the 
logical file structure, so if having both was causing problems we could 
filter out the /dev path.

> getFreeSpace is relatively easy.  statfs will return the freespace from 
a 
> path, so scale that to kilobytes (do you mean kilobytes or kebibytes?, I 

> suspect the latter as ISO define kilo to mean 1000 and kebi to mean 
1024).

I meant 1024

> getLabel is a little more difficult, as there appears to be no direct 
API
> for getting the label, rather one has to read from an absolute position 
on
> the drive.  This works fine for ISO9660 formatted CDs, but not all CDs 
are
> ISO9660 formatted.  Do you only want it to work with ISO9660 media, if 
not
> you will need to list the other formats you want to work.  I think, but 
do
> not know, that DVDs will work as CDs in this respect, but what of CDs 
that
> are formatted as EXT2 or FAT or whatever (which is quite possible and 
legal).
> However that said, getting the label is only a few lines of code for 
ISO9660.

This information is only used for display purposes, so would like to cover 
the cases that are supported/ easy to do. If you can't tell, return null 
(as per javadoc).

> getType is all together more problematic.  WINE ducks the issue, and 
does it
> according to the type specified in their configuration table. 
VOLUME_FIXED
> and VOLUME_REMOVABLE are probably not too difficult, but VOLUME_REMOTE 
is
> well nigh impossible.  It is possible to detect that a mount point is 
mounted
> using a known file system which is remote, such as SAMBA, NFS, AFS, but 
as 
> far as I am aware there is no bit that says this is a remote file 
system.
> The problem here is that we would fail to detect unknown remote file 
systems
> as remote.  Is this a problem?  What is this information being used for?

Again, this information is only used for display purposes (icon selection, 
etc) so supporting only what the native system provides is OK. For the 
other cases returning unknown, or whatever type is indicated by the native 
system is OK. 

Vlad