I have a FAT32 MicroSD card, where my device creates a folder named '$Recycle.Bin' in the root, with hidden+system attributes set, but Windows doesn't recognize it as a real recycle bin (with the correct icon, etc.).
How can I trick Windows into seeing the folder as genuine bin?
I am writing firmware for the device (an ARM datalogger), that has to create the folder using the FATFS library in C. I could ask for example code, but I can write the code myself if someone can point me in the correct direction. All forms of the answer are welcome.
Related
I need to update an existing C program at work to add a method to find the serial number of a drive that contains a given folder. (I am mainly a Java developer and know nothing about low-level Windows calls in C. I have not previously interacted programatically with Windows hardware or system configuration.)
I found a post that gives MFC code for finding the serial number of a drive, given the drive's number at http://codexpert.ro/blog/2013/10/26/get-physical-drive-serial-number-part-1/. (The application I will be updating is not MFC, but am hoping I can modify the code from that page to work for me.)
If possible, I would like to be able to call my new method with the drive number containing a specific folder.
Is there a programmatic way to find the drive number for the folder, based on folder path?
The application will be running on Windows 7 and later.
We have a bootable USB stick that works perfectly. It will boot, ask the user for some options, then write files to the hard drive accordingly. We did this by using rufus-2.1, throwing freedos into the USB stick, and basically hijacking autoexec.bat. Autoexec.bat now executes some separate .bat scripts based on user input.
The problem is, we now want to have an option to allow users to burn an iso to a cd or dvd. We've been trying to create an image of the USB stick and burn it to a DVD.
We found plenty of information on this subject, but nothing has worked. We started by extracting the bootimage from various bootable iso files using imgburn. None of these worked. We tried extracting the bootimage from our USB stick, and that also didn't work.
Next we tried WinImage. We extracted the boot information from boot98.exe, hijacked autoexec.exe, created a new image and injected the files. We saved the files as a bootimage and tried the above method again, which also didn't work.
Is there perhaps a more straightforward way to execute DOS .bat scripts through cd/dvd boot? We'd be open to something other than DOS as well, as long as it can write files to a hard drive based on user input through a simple boot interface.
Note: The computer itself does not contain an operating system.
Thanks.
We found a very slick setup that does what we need. Unfortunately, the CD-ROM drivers do not work properly on modern DVD drives. Using this method, it should be possible to put all the scripts directly in autoexec.bat and run commands directly on the "simulated" floppy drive. For whatever reason, we can boot from the "floppy" section of the CD-ROM, but it cannot copy files from A: to C:. I believe we are very close, but no cigar.
http://www.hiren.info/pages/bootablecd
First method that actually produced a bootable CD and allowed scripts to be run by a choice entered by the user.
IS it at all possible to set the Google homepage to a file located on my USB pen drive?
I can link it though the file path, problem being the drive letter would change depending on the system it is plugged into so a hard coded homepage link wont work.
Im unsure of the syntax to use to make it upen the file -
%USBDRIVE%/Webfiles/index.html
The page is used to help new users navigate the USB pen and get the info/files they require as its aimed as users with next to no IT skills or disabilities
Thanks Guys
You've probably found a solution already, but just come across your question and I recently had the same scenario. I'm assuming you mean on PC.
I solved it as follows:
In the PortableGoogleChrome folder (after portable chrome is setup on the usb drive), there is a default file called parameter.txt. I added the following in order to set the homepage to my local file. It is in a sub folder called 'resources' located on the usb drive root:
--homepage="\resources\index.html"
That's all for the parameter.txt file. That takes care of the homepage setting.
Now to launch portable chrome, I created a windows batch file called launcher.bat also at the root of the usb drive (call it whatever you like obviously!). I added the following code:
#echo off
cd PortableGoogleChrome
"ChromeLoader.exe"
The launcher file changes the directory to PortableGoogleChrome and then loads Chrome via ChromeLoader.exe which takes in your homepage or other parameters in Parameters.txt.
FINALLY, in order to create an application to replace the Launcher.bat file (as I figured a windows application with icon would be more intuitive to run than the batch file), I found a windows utility called bat_to_exe_converter which enabled me to convert the bat to an exe and supply an icon also (having tried to do so in C++, C# but errors because of needing supporting DLL's, this was much more straightforward).
Hope that's of use!
I am working at an OS independent file manager, and I divide files in groups, usually based on the extension. On Linux, I check if a file has the executable permissions or not, and if it does, I add it to the executables group.
This works great for Windows or Linux, but if you combine them it doesn't work so well. For example, while using it on Linux and exploring a windows mounted drive, all the files appear to be executable. I am trying to find a way to ignore those files and not add them to the executables group.
My code (on Linux) uses stat:
#ifndef WINDOWS
stat(ep->d_name, &buf);
....
if(!files_list[i].is_dir && buf.st_mode & 0111)
files_list[i].is_exe=1;
#endif
The first part of the answer is to find what filesystem the file is mounted on. To do that you need to find the filesystem using the st_dev field of the stat information for the file. (You can also do this by checking the file path, but you then have to check every path element for symbolic links).
You can then cross-reference the st_dev field with the mount table in /proc/mounts using getmntent_r(). There's an example of that in a previous answer. The mnt_type field will give you the text of the filesystem type, and you'll need to compare the string with a list of Windows filesystems.
Once you've found the filesystem, the only way to identify an executable is by heuristics. As other people have suggested, you can look at the file extension for Windows executables, and look at the initial bytes of the file for Linux executables. Don't forget executable scripts with the #! prefix, and you may need to read into a Jar file to find out if it contains an executable static main() method.
If you are browsing Windows files then you need to apply Windows rules for whether or not a file is executable. If the file extension is .EXE, .COM, .BAT, or .CMD then it is executable. If you want a more complete list then you should check MSDN. Note that it is possible to add registry entries on a machine that makes any extension you want to be considered executable, but it is best to ignore that kind of thing when you are browsing a drive from the network.
The fact is that you are fighting an uphill battle. The reason all the files have executable permissions is that the windows filesystem driver on Linux allows you to specify that as an option. This masks whether or not any files are Linux exceutables, for instance.
However, you could look into the file header for EVERY file and see if it is a Linux ELF executable (just like the Linux file command does).
It might be helpful to start by checking all the information about mounted filesystems so that you know what you are dealing with. For instance, do you have a CIFS filesystem mounted that is actually a Linux filesystem served up by SAMBA? If you enumerate every bit of information available about the mounted filesystem plus the complete set of stat info, you can probably identify combinations that act as fingerprints of the different scenarios.
Another option I could imagine, is to call the file util, and depend on its output (maybe its enough to grep for the words executable / script). This util exist/is compileable for windows (basically it just checks for some magic bytes in the files), too.
I have started coding an FTP client application (for fun). I’m trying to represent remotely hosted files with icons. For example, let’s say I’m browsing the root folder of an FTP server (/) and want to display the Backup.zip file with the icon association from that client operating system. On some systems, this may be the windows compression icon and other operating systems this may be WinZip or WinRAR icons.
I have the client browsing local files with the SHGetFileInfo() function. This works great with files that are local, however, this function requires the physical file in order to retrieve the associated icon. So, this will not work with remotely hosted files. I have found some samples of loading icons given a file extension, and this is really where the question comes in... What would be the best strategy to get icons associated to remote files?
Go to the registry every time and look up extension to icon associations
Create 1 byte files with each extension and use the SHGetFileInfo() function for remote files (using local 1 byte files as association for remote files)
Other strategies???
What would a professional software company creating an FTP client do?
Thank you for your time.
-Jessy Houle
I suggest that you don't go to the registry every time: go if you need to, but if you've already been for a given filetype then remember/cache that result (within your program) and reuse it.
Use the procedure here from a previous Stack Overflow question on the same idea and uses the registry instead of an actual file.
How can I get the filetype icon that Windows Explorer shows?