Why I try to open NTFS stream named "file:stream" using CreateFile() - that's OK.
But when file is "H" and I got flash card reader on drive H:, CreateFile() tries to open file named "stream" on flash card, because argument passed to CreateFile() is "H:stream"!
How these named streams should be opened correctly?
In this oddball case, you can simply prepend .\ in front of file name or use full file path. For example, this works for me as expected:
.\H:stream
Related
SetFileTime says that it must be given a handle opened with CreateFile referring to a file or directory. But what are the proper parameters to open a directory with CreateFile ?
A friend gave me some files on a USB drive that was formatted as NTFS. From his Linux system he copied a file containing a ? (e.g. "Which way to Millinocket?.mp3"). I can not copy that file using my Windows 10 system. Not from Windows Explorer nor from the cmd prompt. I get an error The filename, directory name, or volume label syntax is incorrect. Del, ren, copy all fail. Dir will show the files, and accepts the actual filename.
>ren "Which Way to Millinocket?.mp3" foo.mp3
The filename, directory name, or volume label syntax is incorrect.
I am looking for a Windows solution. Yes I can bring the drive back to my friend. No I do not have my own Linux system. Is there a way to escape the ? such that I can rename the file?
Using Windows, display the file in Explorer.
Click on the file name.
Press the F2 key, and rename the file.
Now go ahead and copy it.
You can use the short 8.3 filename which every file under windows still has for compatibility reasons.
List the files using dir /x. The list will contain the 8.3 filenames with tilde (~) symbol in the name. You should be able to rename the file using the rename command and giving the 8.3 filename as old filename:
ren "8.3 filename" "some new filename"
so if I've created a temp file in temp directory, used it and now I need to remove it(or them), should I call first file.Close() and then os.RemoveAll, or if I call os.RemoveAll it is unnecessary to close files? Is then file descriptor freed?
On linux removing a file causes its name to be removed from the file system but the block of storage will remain on disk while you still have an open file descriptor and removed only once that file descriptor (and any other file descriptors opened on that file) is closed. See https://linux.die.net/man/2/unlink
In go, the open file descriptor will not be closed just because you call os.RemoveAll() on a directory that contains the file.
I believe microsoft windows works differently: I think you will get an error when you try to remove a file that's currently being written to. That could be wrong, I'm no expert on Windows. But again, the open file descriptor will not be closed automatically.
If I open a file in Windows, that was downloaded by chrome or another browser Windows popups a warning, that this file is downloaded from the internet. The same for documents you open in Microsoft Word.
But how does windows know that this file originate from the Internet? I think it's the same file as every other file on my hard drive. Has it to do something with the file properties?
Harry Johnston got it!
Had nothing to do with temporary folder or media cache. It's a NTFS Stream.
For further reading: MSDN File Streams
This blocking information is archieved with the following commands on the CLI:
(echo [ZoneTransfer]
More? echo ZoneId=3) > test.docx:Zone.Identifier
This creates an alternative file stream.
When you download any file from internet. It first downloaded in Media Cache instead of temp folder. Only after that it moves to actual location where you select to save that file.
If you copy and paste some file then it move that file through Temp folder only. Before opening any file windows check the location and if it is Media Folder then you get the error "File is downloading or other errors related to this".
In Windows Explorer, when you open a ZIP file and double-click a file, say a JPEG file (.jpg), Windows extracts the JPEG file to a temporary folder, and passes the temporary file name to the associated program as the one and only argument, such as "C:\Users\jprice\AppData\Local\Temp\Temp1_<>.zip\<>.jpg"
I noticed that some applications, like the Windows Photo Viewer in Windows 7 know what ZIP file the temporary file came from. You can click next and previous and get the next/previous files from the ZIP file (as you do, they are also extracted to temporary files).
I've googled and prowled through system.io.packaging, but I can't figure out how to get the path of the original ZIP file (the file name is part of the temporary file path).
It's not done with the shell-->open command, Windows Photo Viewer only gets the temporary file name as far as I can tell.
The Photo Viewer command line is
%SystemRoot%\System32\rundll32.exe "%ProgramFiles%\Windows Photo Viewer\PhotoViewer.dll", ImageView_Fullscreen %1
Which doesn't help. I did use ProcessMon to watch Photo Viewer and saw it read the .zip file (probably using zipfldr.dll) but could not discover how it knew where the original zip file was.
When I try it, I notice that WinZip initializes the spawned process's current working directory to the folder that the .zip resides in. If you can extract the .zip filename from the temp file path (and older OS versions did not do that), then you can reconstruct the original .zip file path.