Is it possible to programmatically push files to a wireless SD card - like a www.eye.fi card?
I use a Mac and thought I could do this using some AppleScript - but have not found a way...
Derek
The eye-fi card relies on image files being written to a specific directory in the card before they'll transfer them. Beyond that it works exactly like a memory card.
Write a file to it as if you're writing a regular memory card, and as long as it's a jpg image file of reasonable size, and in an appropriate directory (something under \DCIM\ probably) and they should transfer.
If you're having trouble, double check that it works with your camera, and find out where your camera puts the images on the card, and duplicate that. You might even try naming them similar names to the types of images your camera produces.
-Adam
It looks like you can treat it just like an external hard drive (plug the memory card in and figure out where the mount point is).
I think he wants to send files to it while its in another device, not plug it in and use it to transmit files like an antena directly connected to the machine.
Related
Environment
Ubuntu-20.04 LTS
Bash shell
Question
How to define specific SD card to specific mount point when multiple SD card is inserted as same time and no UUID?
Background
I am working on a bash script which used to copy daily generated image from 2 cameras (front/rear-view) stored in coresponding SD card. The workflow would be somethings like this:
Manually extract the SD cards from cameras (SD cards are labelled and assume they are inserted in correct order, e.g. front-camera always comes with the "A" SD card.)
Insert to the SD card readers that already plugged into the host pc, ( /dev/sda and /dev/sdb )
Automount to desired path , e.g. /media/user/front-sd-card and /media/user/rear-sd-card
Run the script (which the source path is pre-defined as above) and start copying from source to dest
Challenge
I found that at this moment if I insert the rear-sd-card first, it will mount to /dev/sda/disk, and if I insert the front-sd-card first, it will mount to /dev/sda/disk. The next one would be /dev/sdb/disk1. So, which one is inserted first, which will be disk and the second one is disk1, this make human error possible...
Assume the operator insert to the correct card reader ( "A" sd card alwasys insert to sda card reader, and so to "B", this also generate human error if they dont follow).
I have run blkid and no UUID for both SD card, so I could not use UUID and set /etc/fstab to automount to correct mount directory.
Expectation
The "A" SD card and "B" SD card alwasys go to the desired mount point so that the script can pre-define the source path for copying to desired destination directory.
The copy task script is alredy ready and in use, but I want to minimise the human error due to the source pathing issue. So far is check manully before running the script.
I also think of adding a function to open a preview image of both Sd cards, and promot the user to answer yes/no, if the sequence is wrong, answer no and exit the script.
Any other suggestion of workflow also welcome.
How to define specific SD card to specific mount point when multiple SD card is inserted as same time and no UUID?
Detect with udev to which card reader the card was inserted and add a udev rule to mount it.
This consist of watching udevadm monitor, inserting the card, then the second, watching the stream what values you can use for the rule. Then write a rule, which will look somewhere like https://github.com/crittermike/dotfiles/blob/master/udev/11-sd-cards-auto-mount.rules or and you can find many examples of udev rules online.
See also See https://wiki.archlinux.org/title/persistent_block_device_naming .
-l /dev/disk/by-path show something might be useful. pci-0000:00:14.0-usb-0:2.3:1.0-scsi-0:0:0:0-part1 for /sda1 and pci-0000:00:14.0-usb-0:2.4:1.0-scsi-0:0:0:0-part1 for /sdb1
Great, so just mount /dev/disk/pci-0000:00:14.0-usb-0:2.3:1.0-scsi-0:0:0:0-part1 /where/you/want/to/mount/one/card and similar for the other one..
If you are using those SD cards on an ongoing basis, you may as well bite the bullet and assign either a UUID or LABEL or both. Those operations are non-destructive to the content of the partition (they warn you that you should always do a backup before performing these operations), but the UUID/LABEL values are permanently changed and can be restored manually IF you kept track of what those values were before the operations.
After you plugged in your SD card (I would do this one card at a time so you know which card is which),
enter mount -l to obtain the current details for mounted devices (specifically options for the SD card which may be required to create an fstab entry).
open gparted,
select the device from the drop-down menu at the upper-left,
then right-click on the line for the partition in question (there should be a "key" icon next to the /dev/${partition}, meaning locked on mounting),
then choose the unmount option.
Now GParted will allow you to make changes to the SD card ... so click and choose carefully! The little key icon should be gone.
If you right-click on the partition again, you will now have options, including
Label File-system
New UUID
Option 1: UUID
If you choose UUID, that will actually update the SD card with a new UUID (replace the previous UUID, or, add one where there was none before).
Option 2: LABEL
Your other option is to create a LABEL on your partition. If you choose that option, not only will it create a label, that operation also replaces any previously existing UUID with a new UUID to signify that the partition has been physically modified, namely a LABEL has now been assigned.
So, basically, Option 2 is the better choice, unless you absolutely must keep the LABEL for code that uses that value.
After that, setting up an fstab entry to perform mount based on UUID={...} or LABEL={...} is up to your preferences. Using UUID has become the standard approach for the most part but you might choose the LABEL approach for FRONT or BACK as labels.
There are many examples available for details on how to do those various steps.
I've got a working Automator workflow which takes any single (one at a time) inserted LUMIX labelled SD card, reads a value from a text file on it and then renames the files on the card
file= dayofmonth_variablefromtext_originalfilename.mp4
find /Volumes/LUMIX/DCIM/*/P*.MP4
then apply filename process to them
and copies them to an SSD.
It watches the /Volumes/ folder for a mount (LUMIX) then does its thing.
The advantage is that then we know which files are copied as they have been renamed.
However I now need this to work concurrently across multiple SD cards on the same machine - we are looking at a four card reader.
So while SD card 1 is copying, someone may insert another or more and we need them all to be processed in the same fashion with their unique identifier from the txt file on the card - or I guess the name of the SD card. We could rename the SD cards to have unique names, but in tests this did not seem to work and we need 8 or more SD cards for our team.
I cannot figure out how to achieve this in automator/applescript as the source folder /Volumes is a single watch point.
Essentially we are trying to avoid people waiting around till a slot is free for them to put the SD card into, with four, it can be slotted in and they can go (that is the idea)
Any ideas?
I am done with my media and i have sterilise my media using sterilise. I just want to check if anyone know of any test/ways/procedure to confirmed that the media is sterilised.
Thanks
Regards
J
Starting with Windows 8, you can do:
Format H: /P:7
I also like Eraser, allows you to wipe unused disk space and schedule.
https://eraser.heidi.ie/
Apparently it's hard to use tools like this on SSDs because of wear-leveling. DBAN won't work for full drive wipes, you need to use the built in erase commands. However, Windows implements TRIM and UNMAP which should securely garbage collect on SSDs.
https://www.howtogeek.com/257196/how-to-check-if-trim-is-enabled-for-your-ssd-and-enable-it-if-it-isnt/
I've got an image that I write onto a bootable USB that I need to tweak. I've managed to mount the stick as /dev/loopX including allowing for the partition start offset, and I can read files from it. However writing back 'seems to work' (no errors reported) but after writing the resulting tweaked image to a USB drive, I can no longer read the tweaked files correctly.
The file that fails is large and also a compressed tarfile.
Is writing back in this manner simply a 'no-no' or is there some way to make this work?
If possible, I don't want to reformat the partition and rewrite from scratch because that will (I assume) change the UUID and then I need to go worry about the boot partition etc.
I believe I have the answer. When using losetup to create a writeable virtual device from the partition on your USB drive, you must specify the --sizelimit parameter as well as the offset parameter. If you don't then the resulting writes can go past the last defined sector on the partition (presumably requires your USB drive to have extra space). Linux reports no errors until later when you try to read. The key hints/evidence for this are that when reads (or (re)written data) fail, dmesg shows read errors attempting to read past the end of the drive. fsck tools such as dosfsck also indicate that the drive claims to be larger than it is.
I have several USB drives connected to a WinXP SP3 computer, and I need to tell them apart programatically - I need to find which drive letter corresponds to which device (in this case, one device ~ one volume). I can get their Volume IDs and drive letters using mountvol, looking something like this:
C:\WINDOWS\> mountvol
\\?\Volume{bdb681b2-1ddf-11dd-bf71-806d6172696f}\
C:\
\\?\Volume{6a8784f8-7406-11dd-a8c3-001e8c829b67}\
A:\
Also, using devcon or the Device Manager, I can see the device IDs:
C:\WINDOWS\> devcon resources *STOR*
STORAGE\REMOVABLEMEDIA\7&190C24E5&0&RM
Name: Generic volume
STORAGE\VOLUME\1&30A96598&0&SIGNATURED84ED84EOFFSET7E00LENGTH2543150400
Name: Generic volume
USBSTOR\DISK&VEN_KINGSTON&PROD_DATATRAVELER2.0&REV_1.00\0803240752536&0
Name: Kingston DataTraveler2.0 USB Device
However, I haven't found a way to link the device ID and the volume ID/letter, like the "Safely remove hardware" dialog does (therefore I assume it's possible):
(source: piskvor.org)
As you may see, these are the same devices that I see in devcon and the same volume that mountvol sees; but so far I haven't found the link between them.
I've found some related questions, but those seem to use the approach "whatever you find first is your USB device", which is not very useful in my case, since there will be several similar devices (same vendor, often same product type) connected.
Edit:
#MSalters' answer looks promising: On XP, HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices has REG_BINARY values \DosDevices\x: (where x is [A-Z]); the comment is (UTF-16) name of the correct device (e.g.
\DosDevices\A: = "\??\STORAGE#RemovableMedia#7&190c24e5&0&RM#{53f5630d-b6bf-11d0-94f2-00a0c91efb8b}\", which corresponds to
STORAGE\REMOVABLEMEDIA\7&190C24E5&0&RM seen above in the device list).
Will see if that's the way to go.
It's a non-trivial question. There is no official API for it, as far as I can tell. So, you need an undocumented API: the registry. HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices contains entries for both drive letters and volume IDs. If you look at the actual data, you'll find that it identifies the drive. Look at the binary data as a Unicode string. It will point you to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ENUM\. However, XP and Vista differ in exactly what subkeys are referenced there, and how. (Vista is easier, so try that first).
There is an official API to do this. See this sample:
http://www.codeproject.com/KB/system/RemoveDriveByLetter.aspx
The principle is that each storage volume on Windows is assigned a global number. First, you ask your drive for its number (by opening "\X:" and sending a IOCTL_STORAGE_GET_DEVICE_NUMBER request). Second, you go over all disk devices and ask each one for its number (by opening it, through a different path, so you can't just string-compare).
Once you find a disk device carrying the same number as you queried your drive, you know you have a winner.