I completely abandoned my old design in favor a fully automatic model. This application automatically detects everything that gets plugged into USB, then test whether or not it is MTP compatible. Each device is only tested once as it records whether the device passed or failed. There is NO need to have a list of MTP compatible devices to make detection possible. That pretty much future proofs the application. I have tested this application in several versions of Puppy and Lubuntu, just for grins. I have also tested it with 9 different MTP enabled devices and 12 devices that do not use MTP, with each computer and distro that I tested. Under the stated test conditions this application is bug free. Now that I am releasing this into the wild I would appreciate it if you post any bug you might possibly find here.

***Install go-mtpfs first***
http://murga-linux.com/puppy/viewtopic.php?t=91442#752416
Usage: after installing go-mtpfs and this pet package, restart your computer OR start the script /root/Startup/MTPconnect.sh
Then plug in an MTP device.
within a second or two your file manager will display the contents of your device.
use your file manager OR the command line to manage your files as you normally do.
After all files on the device are closed (ie. you are no longer copying, moving, streaming, etc.) unplug the device. There is no need to unmount first. The data integrity on your device will not be harmed.
Within a couple seconds of unmounting the application corrects all conditions left by unplugging your device, so that no errors are generated in the FUSE or go-mtpfs layers (ie. the file systems of the device and your computer are left error free).
Data integrity on the device can be compromised if you unplug your device while you still have files open (ie. copying or moving). You have been warned.
On the other hand my test have shown that using the fusermount -u command to unmount while a file is open produces at best a "device or resource is busy" error that is sometimes only curable by rebooting the computer and at worse causes data integrity issues on the device.
another event that can cause the "device or resource is busy" error is to cancle a move or copy before it completes. This is the case whether or not you use this application to automount and/or autounmount your device.

Note: This application is not compatible with my other MTP automounter application, 01micko's similar application, or Geoffrey's script that is included in Carolina 1.2. In the case of my previous application and 01micko's application, simply uninstall the PET package before installing trying this one and if you if you want to switch back, then uninstall this package, before reinstalling whatever you were using before. In the case with Geoffrey's script, there is no need to uninstall his script, just don't use it while this package is installed. If you don't have any of the packages mentioned in this note, then just use the simple install instructions mentioned above.

Edit:
If you are interested in an explanation as to why it is safe to unplug your MTP device after all the files are closed, without issuing an unmount command. I explain this here in response to the second question from Sylvander:
http://murga-linux.com/puppy/viewtopic.php?p=756504#756656

***Edit***
I have tested MTPconnect with a friends phone that has a custom Android ROM and discovered a problem. His phone mounts perfectly the first time each session, but on each subsequent time that I plug his phone in I have to unplug and plug it in a second time before it will mount. I don't know the issue yet, but I will figure it out and include a fix in version 1.0. For now if you experience something like this just unplug, then plug in again.then post your experience here (please include model and which ROM if you are using a custom ROM). I think this might have something to do with the custom ROM on this phone, but I am not entirely sure yet.
***Blackberry***
It is known that Blackberry playbook and possibly other blackberry devices do not work with go-mtpfs. there is nothing I can do about this, as MTPconnect does not modify go-mtpfs in any way. At the time of this writing I do not know of any good solutions for Blackberry Playbook, but if I come across something I will start a new thread for the topic

MTPconnect_0.9.pet

Description

Install this package after you install the go-mtpfs package from Tempestuous, I linked to above.

QuestionIs this version applicable to 64bit PUPs as well as the 32bit PUPs?_________________Get ACTIVE Create Circles; Do those good things which benefit people's needs!
We are all related ... Its time to show that we know this!
3 Different Puppy Search Enginesor use DogPile

QuestionIs this version applicable to 64bit PUPs as well as the 32bit PUPs?

It should not make any difference if you are using a 64 or 32 bit puppy.
Edit: Just to be clear. MTPconnect doesn't care if you are using a 64 or 32bit operating system, but you do need to get the correct version of go-mtpfs. They are both available at the link in the first post of this thread. I know that you are already aware of this, but I thought I might include it for other peoples benefit.Last edited by can8v on Thu 06 Feb 2014, 12:51; edited 1 time in total

After installing MTPconnect 0.9, starting /root/Startup/MTPconnect.sh, plugging in my device, a new directory appeared: /mnt/M470BSA
A green dot on the directory icon indicating it is mounted.

I unplug my device. /mnt/M470BSA does not go away. I right-click>unmount.

I uninstall MTPconnect 0.9.
I install (like I have done before):
mtp_detect-0.11-exper-noarch.pet
mtpstatus-0.3-i486.pet

I plug in my device. The directory (with the dot), /mnt/M470BSA appears, but none of the contents are accessible.

A dialog appears (at the same time as /mnt/M470BSA appears) that offers to mount my M470BSA. Sometimes it mounts successfully, other times mounting fails. Even if mounting is successful, the contents are not always accessible.

I am not sure what is going on here.

EDIT:
After I uninstalled MTPconnect 0.9., /root/Startup/MTPconnect.sh was still running. Two instances of it actually. After I used sigterm on them, then mounting of my device, and accessing the contents, appeared to work correctly.

EDIT:
I was writing the first edit when this post was replied to. Thanks for the info can8v.Last edited by version2013 on Thu 06 Feb 2014, 00:16; edited 2 times in total

After installing MTPconnect 0.9, starting /root/Startup/MTPconnect.sh, plugging in my device, a new directory appeared: /mnt/M470BSA
A green dot on the directory icon indicating it is mounted.

I unplug my device. /mnt/M470BSA does not go away. I right-click>unmount.

I uninstall MTPconnect 0.9.
I install (like I have done before):
mtp_detect-0.11-exper-noarch.pet
mtpstatus-0.3-i486.pet

I plug in my device. The directory (with the dot), /mnt/M470BSA appears, but none of the contents are accessible.

A dialog appears (at the same time as /mnt/M470BSA appears) that offers to mount my M470BSA. Sometimes it mounts successfully, other times mounting fails. Even if mounting is successful, the contents are not always accessible.

I am not sure what is going on here.

The two programs are not compatible as stated in the release notes. It sounds like MTPconnect installed and functioned correctly, then you uninstalled it and reinstalled Mick's program, but did not stop the MTPconnect process first. That is an easy step to miss as it runs in the background and is invisible to the user. Simply open a task manager and kill the MTPconnect.sh program and Mick's program should once again function normally.

I suspect that Mick's application wasn't fully uninstalled when you tried MTPconnect either, as it does not have a right click unmount option, it simply unmounts automatically after you unplug your device. Unfortunately if there is a way to have PPM kill a programs running processes during uninstall I don't know what it is. I will look into this possibility.

Note: This application is not compatible with...01micko's similar application...in the case of...01micko's application, simply uninstall the PET package before installing trying this one...

PROBLEM:
I installed 01 micko's pet's [and they are functional], but they don't show in the PPM, or "Check dependencies", so how should I uninstall them?

Is it essential to uninstall them prior to any attempt to installing yours and using it?

It is important to not only uninstall, but also to kill the running processes or restart your computer. Since you have the other packages installed and they work, you might try booting with the pfix=ram option to ensure it is not installed then install go-mtpfs and MTPconnect, try it out. If you like this approach better, then we can figure out how to uninstall the other package. Although I cannot imagine why Mick's program doesn't show up in the PPM. That question might be better addressed by him. Using that approach if you decide you don't want to keep using MTPconnect then, just reboot normally and you will be back to your usual setup.

b. When I plugged in the tablet, the Pupcamera window appeared, then an Xfe window appeared.
I used the Xfe window to navigate to the folder/file system under the /mnt/GT-P5110/Tablet folder.
At 1st view there was no content, but as soon as I did something it seems the view refreshed and the content appeared.

c. I copied all of the folders/files to a backup folder on a [USB connected] external HDD.
That worked just fine.
So I now have a backup of the content on the tablet.

d. Right now, the tablet is still connected, and [all "Copy to" having completed, and having shut down the only Xfe window, and then re-run Xfe] the content can still be seen.
I'm somewhat wary of un-plugging the tablet [without dis-mounting it], even though all operations have completed and all Xfe windows closed.
Can you re-assure me that it's OK to disconnect?
To play safe, I'll close Puppy down and power-off before disconnecting.

At 1st view there was no content, but as soon as I did something it seems the view refreshed and the content appeared.

This is because when the application opens your file manager for you it opens it to the mount point. The mount point is actually the parent directory to the directory that contains the content of your device. For example when I plug in my phone The MTPconnect detects the product name as "ANDROID_PHONE" (not real creative on the part of the phone manufacturer), therefore MTPconnect creates the mount point (a directory same as any other) at /mnt/ANDROID_PHONE. The mount point does not contain the actual content of the phone, but rather a content directory (a child directory of the mount point) call NAND_FLASH. So the path to the content is /mnt/ANDROID_PHONE/NAND_FLASH that is where I find my Movies folder for example. So "as soon as [you] did something" it would make sense that you would see some content appear, as you likely opened the content directory. In your case (based on your post) I would say your content directory is "tablet".

Sylvander wrote:

I'm somewhat wary of un-plugging the tablet [without dis-mounting it], even though all operations have completed and all Xfe windows closed.
Can you re-assure me that it's OK to disconnect?
To play safe, I'll close Puppy down and power-off before disconnecting.

By making MTPconnect totally automatic I had hoped to spare the end user what I am about to share with you, as most users will never want to know this much detail. It is however, very rational for somebody who has been using computers over the last decade to be skeptical about unplugging a device without unmounting it first, especially Linux users. Linux users tend to be more educated about such issues as they are more exposed to there computer's OS and hardware and its software doesn't generally hide such things in background processes as much as other operating systems. That said. i will briefly explain the reason for unmounting and why it does not apply here.
Until relatively recently almost all devices that stored media that plugged into a USB, FireWire, eSATA, or other such port were block devices. Devices that use MTP are not block devices. They are not mounted as block devices. Each file is mounted individually on an as needed basis. This is why once all files are closed on the device it is safe to unplug it, because essentially it is already unmounted. When the file is closed, that file is essentially unmounted. When all files are closed the device is completely unmounted. This is a purposeful part of the design of the system. This provides one major advantage; both the device and the computer it is connected to can access the NAND flash or SD card at the same time. The inherent disadvantage however, is that say your device deletes or moves a file, your computer will not be aware of the change until the device is remounted (though this is not particularly true in the reverse ie your computer deletes a file your device will see the change).
So why does the go-mtpfs/FUSE layer have an unmount command (fusermount -u)? Linux was not designed with MTP in mind, this is a MS protocol. Linux excpects to mount block devices. go-mtpfs/FUSE layer helps *nix type operating systems mount MTP in much the same way that it mounts block level devices, an adapter or translator if you will. This is why even though your device does not require your computer to unmount prior to disconnection and is just as happy if you don't, your computer is going to experience I/O errors (ie. Transport end point not connected, Symbol look up, and other such errors are quite common). Throughout the course of developing my first automounter for go-mtpfs I encountered 5 different types of errors fairly regularly (if I didn't mount unmount exactly the way prescribed in Tempestuous' original post on go-mtpfs). The go-mtpfs development site states clearly that it is safe to unplug when your files are closed without "unmounting", but that I/O errors will occur. Through the process of testing, retesting and testing hundreds more times I discovered that to be the truth. I never experienced any data integrity problem on my device or my computer if the files were closed prior to disconnecting regardless if I used the fusermount -u command (because if the files are closed the files essentially are not mounted). This did however, cause the expected I/O errors.
That is why I created MTPconnect. MTPconnect completely automates the mount proceedure, detects the protocol of all devices (as either MTP or not MTP) and records that data, so that it only needs to be done once. And most importantly cleans up all of the conditions left on your computer after you unplug your device that would otherwise cause I/O and other errors. With these conditions cleaned up your computers file system is completely accessible. If those conditions are not cleaned up, then the parent directory of the mount point and all of its subdirectories could be rendered inaccessible until they are cleaned up. In our case the mount point is always a sub directory of /mnt that means if these errors are not cleaned up then /mnt and all of its subdirectories would be inaccessible until the error causing conditions are corrected.
On the bright side the FUSE layer comes with all the tools necessary to correct these conditions. The average user however, is not going to go study FUSE, then go to the command line and correct these conditions. I personally don't think that the average user should have to go to that much trouble either. That is why I included this in MTPconnect.
While this is probably more than most people ever wanted to know about MTP, hopefully it will be informative for some people and put your anxiety about unplugging your device without issuing an unmount command to rest. Just to be clear though I am only suggesting this be done with MTP devices. ALL block devices should be unmounted prior to unplugging them, but MTP devices are not block devices.

1. "The mount point is actually the parent directory to the directory that contains the content of your device".
I was aware of that when trying to find the content, but [at 1st viewing] there was only an EMPTY "tablet" folder, with NO SUB-FOLDERS [or files] below.

2. "it would make sense that you would see some content appear, as you likely opened the content directory".
When I first opened the "tablet" content directory, it was empty....
So I did something [can't remember what]...
Possibly I closed the Xfe window, then re-opened an Xfe window...
And next time around, the content was there.

3. "Devices that use MTP are not block devices. They are not mounted as block devices. Each file is mounted individually on an as needed basis. This is why once all files are closed on the device it is safe to unplug it, because essentially it is already unmounted. When the file is closed, that file is essentially unmounted. When all files are closed the device is completely unmounted."
Thank you for the detailed explanation.
I read it a couple of times, and believe I understand.
I certainly get the general idea.
Nice to hear that your program cleans up afterward, and there will be no nasty after effects from un-plugging the tablet.

In using MTPconnect, it initially made a directory under root/my-applications/bin with the Kindle and all of its sub-directories. The second time, the same directory was blank so I kept rebooting to try and fix ... no luck. Then, after about 5 reboots, I noticed through Rox-Filer that the Kindle mounted as mnt/Kindle (which it may have been doing all along). Is this an error of some sort or it MTPconnect designed to do this? I actually liked the folder showing up in root (for carving purposes) but it's not a big deal. I just didn't know it was mounting until I went into Rox-Filer to check.

MTPconnect never mounts under root. It will always mount under /mnt/(product_name). Think perhaps you just didn't realize the actual mount point the first go around. At any rate simply unplugging your Kindle and plugging it back in should cause ROX to open to the mount point.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum