Linux: mount devices

[leo_08_15]

I wonder, why the removable devices are not listed in the DrivePopupButton. Tracking down I find in LocalFile something like

Code: Select all

           // Add java.io.File's root folders
            addJavaIoFileRoots(volumesV);

            // Add /etc/fstab folders under UNIX-based systems.
            if(OsFamily.getCurrent().isUnixBased())
                addFstabEntries(volumesV);


According to http://www.pathname.com/fhs/pub/fhs-2.3.html#MEDIAMOUNTPOINT the media-folder can be used. But here I have to following problem:

LocalFile cannot be changed, cause LongByReference is undefined. As soon as I change something therein, I get a compilation error. Any ideas, how to add that kind of function?

Does it make sense to give them as well an own icon? If so, from where to retrieve it? From the system????

LeO

[leo_08_15]

My second problem what I now patched right now, is that the mounting has problems when the drive is not any longer available.

Big Question: How long should I wait to contiue? i.e. how long should there be the timeout set, before continue? If the timeout is too low, then it is recognized wrongly, if too high, than toooo long wait.

Java does not recognize it, cause Linux also not recognize it. I have set it currently to 5 seconds. Is this reasonable?

Please take care, that the DrivePopupButton takes that amount of time to wait till the files are displayed. 5 seconds?

Since I use this time in two places, is there a good place where to store them both and use it from the same place? Something like GlobalVariableClass.java???

[kowy]

Hi leo,
I've already sent patch, which get currently mounted drives from /proc/mounts file. It works pretty, you can see removable drives immediately after they are connected to the system. You can see my patch here:
http://trac.mucommander.com/ticket/227

[leo_08_15]

Hi kwoy,

things are getting interesting. Cause your patch applies to LocalFile. My patch for

http://trac.mucommander.com/ticket/224

applies as well to LocalFile. I have to admit, that my code is reformatted and therefore not easily perceivable, what was changed. For the same routine you changed I changed it that way to query

Code: Select all

isFolderUsable(...)

I mean I changed as well

Code: Select all

public FileURL getParent()

( I hope I remebered clearly, that these two changes were the only ones).

Anyway, I have no clue, how to proceed. I.e. does it make sense that I fuse your patch and mine togehter and place it in #224? Or should we leave them separate and maxence should make the fusion? Or you volunteer? ????

LeO

[kowy]

Hi leo,
sorry, but I don't understand neither your problem nor your patch. Really it wasn't a good idea to change formating of a whole document. I can't identify your changes. Maybe it is much easier to place my changes to your patch. Simply replace whole addFstabEntries method with addMountEntries method and also all references (calling method). Or send me your LocalFile.java and I will merge it on my computer.

[leo_08_15]

Hi kwoy,

reformatting the whole patch I did reallize it much toooooo late and seems a real dilemma. And I have currently not much idea how to progress for this issue, cause it seems too crossconnected in many files. As I mentioned in your ticket, I have tested resp. placed your patch and it works great.

I think maxence might have the same problem to identify my changes, therefore I placed the whole changed files in the ticket. I feel little reluctant to do the work of repatching cause I am not really sure if it is useless or not.

When I read

I don't understand neither your problem nor your patch

then I don't understand either what is unclear. In the ticket I have clearly described what scenarios are fixed. So, would you mind to give me clue where I could assist? What is in specific unclear what is not mentioned in the ticket and not here?

Rem: I have attached all source files in the ticket - reformatted them once again to produce less changes. Due to some svn-plugin-problems I couldn't create the patch once more. So, please check the last attachments and not the patch.

[kowy]

Hi leo,
the think I don't understand is "lack of timeout-handling". I don't know whad do you mean with it.But it doesn't metter.
Because my patch is much smaller then yours, I added my changes to your file and append here. You can simply diff it your old file.

Did it help you? Or do you need any more help from me? Also I don't have write access to subversion, so we must both wait until merge our patches to production.

One more hint. You can simply checkout mucommander to another directory then copy your changed files (appended in #224.7z) to proper directories and svn diff should work again. I did it several time svn working copy broken. What svn-plugin do you use?

[leo_08_15]

Hi kowy,

just for small expleantion about 'lack of timeout-handling': when debugging mucommander in some parts I recognized that Java-methods file.list() blocks forever if e.g. Ubuntu does not report the given dir is not there. this could be the case, when you have mounted a network-dir and then wanna work as standalone, i.e. no network any longer ==> file.list() waits forever until you plugin back the network.

and I am really surprised to see, that this was not yet handled with wrappers around the file.list() [or similar methods], cause I would have assumed this is one of the standard-scenarios. in Linux this could occur at the startup when the FSTab points to one dir not any longer there and you wanna mount it. then mucommander hangs forever and ever.

about the access: I do not have either and somehow this sucks. especially when submitting patches some weeks ago and no reasonable response. sorry, but I'm getting frustrated about how this works here.

[kowy]

Hi leo,
yes I understand you. I have a very similar feeling. I send my patches here:
viewtopic.php?f=8&t=784
and here:
http://trac.mucommander.com/ticket/227

Also I sent my patch file to mail also without sucess. No replay for a month or even more. It is really demotivating